ჰკითხეთ ათ სენიორ-ინჟინერს, კარიერის დასაწყისიდან რომელ ტექნოლოგიას იყენებენ დღემდე ყოველ კვირას, უცვლელად. JavaScript-ფრემვორკს ვერ გაიგონებთ. გაიგონებთ SQL-ს — ენას, რომელსაც „აი-აი ჩაანაცვლებენ“-ო, დაახლოებით ხუთ წელიწადში ერთხელ აცხადებენ 1986 წლიდან, ბოლოს — AI-ის მოსვლასთან ერთად. და აი შედეგი: AI-სისტემები, რომლებიც თითქოს მას ანაცვლებენ, გასაოცარი ხარისხით აღმოჩნდნენ SQL-ის გენერაციის მანქანები — SQL-ისა, რომელიც ადამიანმა მაინც უნდა შეამოწმოს.
თუ IT-ის შესასვლელთან დგახართ და ფიქრობთ, რა ისწავლოთ პირველად — ან უკვე პროფესიაში ხართ და გინდათ ერთი ნავიკი, რომელიც თქვენს ღირებულებას ყველა ტრეკში ზრდის, — აი გულახდილი არგუმენტები SQL-ის სასარგებლოდ.
რატომ ღირს SQL-ის სწავლა პირველად დღემდე?
იმიტომ, რომ ეს იშვიათი ნავიკია, რომელიც ერთდროულად დამწყებთათვის მეგობრულია, ყველგან მოთხოვნადია და მუდმივია. სინტაქსი, რომელსაც პირველ კვირაში ისწავლით — SELECT, JOIN, WHERE, GROUP BY — იგივე სინტაქსია, რომელიც მუშაობს თქვენს დაბადებამდე დაწერილ პროდაქშენ-სისტემებში და სისტემებში, რომლებიც გასულ კვირას გამოვიდა. თითქმის ყველა აპლიკაციის უკან, რომელიც ოდესმე გამოგიყენებიათ, რელაციური ბაზა დგას, და ყველა ტრეკი IT-კარიერების რუკაზე — backend, frontend, data, DevOps — ასე თუ ისე მას ეხება.
ფრემვორკის ნავიკი უფასურდება, როგორც ავტომობილი. SQL-ის ნავიკი პროცენტებს აგროვებს, როგორც საინდექსო ფონდი. ახლა ჩადებული ოცი საათი მთელი კარიერის განმავლობაში იხდის დივიდენდებს — ამას ვერცერთ ფრემვორკზე ვერ ვიტყოდი, რომელიც მისწავლებია.
და „ყველა ტრეკი მას ეხება“ ადვილად სათქმელია — აი, კონკრეტულად რას გაძლევთ ის თითოეულში:
| თქვენი ტრეკი | რას ხსნის SQL სწორედ იქ | რეალური ამოცანა, რომელსაც ერთი კურსის შემდეგ აიღებთ |
|---|---|---|
| Backend | Schema-ს დიზაინი, მოთხოვნების წარმადობა და ORM-ის ქცევა, რომლის დებაგვასაც რეალურად შეძლებთ | დაამატოთ საანგარიშო endpoint, რომელიც რეალურ მონაცემებზე ტაიმაუტში არ ვარდება |
| Data და ანალიტიკა | აგრეგაცია, join-ები წყაროებს შორის — სამუშაოს ყოველდღიური რეალობა | თავიდან ააწყოთ დაშბორდის ციფრი, რომელიც არასწორად გამოიყურებოდა — და დაამტკიცოთ, რომელი იყო სწორი |
| Frontend | API-ის მონაცემთა ფორმის წაკითხვა და იმის ცოდნა, რის მოთხოვნაც ძვირია | ახსნათ, რატომ სჭირდება სიის endpoint-ს pagination ყველაფრის დაბრუნების ნაცვლად |
| DevOps | მიგრაციები, backup-ები, აღდგენები და ნელი მოთხოვნების ტრიაჟი | დაადგინოთ ღამის 3 საათის ბაზის alert-ის მიზეზი ესკალაციის ნაცვლად |
AI ხომ თვითონ წერს ახლა SQL-ს?
წერს — და სწორედ ეს ზრდის SQL-ის გაგების ღირებულებას და არა ამცირებს. მოდელი სიამოვნებით დააგენერირებს მოთხოვნას, რომელიც ეშვება, აბრუნებს რიგებს — და მაინც არასწორია: JOIN, რომელიც შეუმჩნევლად აორმაგებს შემოსავლის ციფრებს, ფილტრი, რომელიც აგრეგაციის შემდეგ არის გამოყენებული და არა მანამდე. ორივე შემთხვევაში მოთხოვნა ავტორიტეტულად გამოიყურება. ადამიანი, რომელსაც მოთხოვნის წაკითხვა შეუძლია, შეცდომას წამებში იჭერს; ადამიანი, რომელსაც არ შეუძლია, თავის CEO-ს არასწორ დაშბორდს უგზავნის.
ეს იგივე პატერნია, რომელიც აღვწერე სტატიაში როდის არ უნდა გამოიყენოთ AI-ხელსაწყოები: AI აშორებს ტექსტის აკრეფას და არა გაგებას. AI-ის ეპოქაში SQL-ის წიგნიერება ჩუმად გადაიქცევა „backend-ნავიკიდან“ „კითხვის ნავიკად ყველასთვის, ვისი გადაწყვეტილებებიც მონაცემებს ეხება“ — და ეს არის სამუშაოების უმრავლესობა, რომელთა ქონაც საერთოდ ღირს.
რის გაკეთებას შეძლებთ რეალურად სწავლის შემდეგ?
სერიოზული პირველი კურსის შემდეგ — დაახლოებით ოთხი კვირა საღამოს მეცადინეობით — შეძლებთ წაიკითხოთ და დაწეროთ მოთხოვნები რამდენიმე ცხრილზე, დააპროექტოთ გონივრული სქემა პატარა აპლიკაციისთვის, გაიგოთ, რატომ ხდის ინდექსი ერთ მოთხოვნას მყისიერს და მეორეს — ნელს, და თავდაჯერებულად იგრძნოთ თავი ბაზების ნაწილში ჯუნიორ-გასაუბრებაზე ნებისმიერ ტრეკში. სწორედ ამ მოცულობას ფარავს SQL-ის კურსი — შეგნებულად და ზუსტად ამ თანმიმდევრობით.
არანაკლებ მნიშვნელოვანია, რას ხსნის ის შემდეგ. Backend-სამუშაო პირდაპირ მასზეა აშენებული — ბუნებრივი შემდეგი ნაბიჯებია გაიგოთ, როგორ ეწყობა ერთმანეთს სერვისები და ბაზები, მოგვიანებით კი — დოკუმენტური ბაზების სამყარო MongoDB, რომელიც ბევრად უფრო გასაგები ხდება, როცა იცით, რას გაძლევენ ცხრილები და რაზე ამბობთ უარს. მონაცემთა ანალიზი, DevOps, თუნდაც frontend-მუშაობა API-ებთან — ყველაფერი ეს მარტივდება, როცა ფეხქვეშ რელაციური საძირკველი გაქვთ.
როგორ უნდა ისწავლოს ის დამწყებმა სწორად?
ისწავლეთ რეალისტურ მონაცემებზე და არა სათამაშო ცხრილებზე ხუთი რიგით. კონცეფციები, რომლებიც გასაუბრებებზე და სამუშაოზე მნიშვნელოვანია — JOIN-ები რამდენიმე ცხრილზე, აგრეგაცია GROUP BY-თ, ქვემოთხოვნები, ინდექსები — მხოლოდ მაშინ „ჯდება“, როცა მონაცემთა ნაკრები საკმარისად დიდია, რომ ცუდი მოთხოვნა ნელად იგრძნობოდეს, ხოლო არასწორმა JOIN-მა თვალშისაცემად აბსურდული ციფრები გამოსცეს. კლასიკური შეცდომები საკლასო ოთახში უნდა დაუშვათ, სადაც ისინი სასაცილოა, და არა პროდაქშენში, სადაც ისინი ძვირია.
და ისწავლეთ ცოცხლად, ადამიანთან ერთად, რომელიც თქვენს მოთხოვნებს ამოწმებს. SQL-ს მატყუარა თვისება აქვს: ყველაფერი, რასაც დაწერთ, ეშვება. არ არსებობს კომპილატორის შეცდომები, რომლებიც გასწავლიდნენ; არასწორობა მხოლოდ შედეგებში ჩანს, დამწყები კი მას ჯერ ვერ ხედავს. უკუკავშირი მისგან, ვინც ხედავს, — ეს არის განსხვავება ოთხ კვირასა და ერთი წლის თვითსწავლას შორის. იმავე მიზეზით roadmap-ი ნავიკებს საკონტროლო წერტილებით აწყობს და არ გტოვებთ გამოსაცნობად.
გულახდილი პრეზენტაცია ერთ აბზაცად
SQL კონფერენციებზე მოდურს ვერ გაგხდით. სამაგიეროდ ის აკეთებს აი რას: ხსნის ჯუნიორის კარებს ყველა ტრეკში, გადაურჩება ფრემვორკების ყველა ციკლს, რომელსაც თქვენს კარიერაში მოესწრებით, გხდით იმ ადამიანად, რომელიც AI-ის არასწორ მოთხოვნას რევიუზე იჭერს, და რეალურად სასარგებლო დონემდე დაახლოებით ერთ თვეში ისწავლება. ტექნიკურ კარიერაში პირველ ინვესტიციებს შორის მე არაფერი ვიცი ასეთი რისკისა და შემოსავლის თანაფარდობით.