Чи важливий SQL, якщо я добре знаю рамки ORM? [зачинено]

У мене немає серйозного досвіду роботи в SQL, і я навіть ненавиджу писати SQL замість LINQ. Я досить щасливий з ОРМ.

З точки зору роботодавців та секторів, чи важливо знати SQL? Чи треба це майструвати? Чи компанії, які віддають перевагу чистому SQL над рамками ORM, є "динозавром" у світі програмування?

Це важко пояснити багатьом програмістам, тому що якщо ви знаєте лише базовий SQL, то він насправді не дає великої переваги перед милістю ORM. Однак більш просунуті концепції SQL є вирішальною частиною різниці між додатками, які просто працюють, та якісно високоякісними програмами (зокрема, швидкими та надійними).

Я припускаю, що хтось інший розробляє бази даних для вас, тому що робити це, не знаючи жодного SQL, - це просто позаду. Але навіть якщо ви лише розвиваєтеся проти них, ось лише частковий перелік усіх речей, які ORM все ще мають тенденцію робити погано або зовсім не:

• Рекурсивні та / або ієрархічні запити
• Необов’язкові параметри (особливо переведення їх у предикати діапазону)
• Визначені користувачем типи даних
• Типи для платформи (ієрархії SQL і TVP, масиви Oracle і вкладені таблиці тощо)
• Пакетні вставки / оновлення / оновлення / видалення
• Підказки
• Підказки про блокування (особливо блокування оновлень та брудне читання)
• Помилка обробки
• Зовнішні приєднуються - їх результат встановлює карту погано для моделі OOP, багато ORM мають власну мову запитів, але це схоже на знання самого SQL;
• Модулялізація за допомогою збереженої процедури та UDF, особливо вбудованих UDF та CROSS APPLY запитів
• Використання виводу / повернення для постановки даних у кілька таблиць
• Ефективні запити підкачки
• Запити на основі функцій вікна (rownum, rank, partitions)

Список продовжується і продовжується - дуже багато таких речей, про які початківці DBA ніколи не мали робити, а розробник-початківець ніколи навіть не чув - але вони є дуже важливими для більш масштабних додатків.

ORM дійсно чудово прискорюють дійсно нудний SQL-код - тобто всі повторювані CRUD-карти та карти та інший сантехнічний код, тому абсолютно не соромно в їх використанні і не слухайте тих, хто каже, що вони злі. Але ви, безумовно, все ще повинні навчитися, і так, навіть освоїти SQL, і бути готовим впасти в необроблені команди / запити БД, коли ОРМ не тягне свою вагу.

Абсолютно! SQL все ще є мовою франків баз даних, і хоча ви можете зробити багато з ORM, вам доведеться розуміти SQL, щоб зрозуміти рішення, які приймають ORM, і SQL, який вони генерують. Крім того, є ще багато речей, які вам доводиться робити з користувацькими sql і збереженими процедурами. Вибачте, безкоштовного обіду немає.

Так, вам ще потрібно знати SQL. ORM - це дуже проникна абстракція і не забезпечує доступ до всієї потужності SQL. У програмах для іграшок вам може бути добре з обмеженими знаннями SQL. Для корпоративних додатків вам доведеться розбиратися в базі даних, щоб отримати гідну продуктивність від ORM. Також існує дуже багато завдань, які набагато простіше виконуватись із SQL, ніж з мовою програми. Я бачив, як програмісти Java проводять дні, пишучи код, щоб зробити щось, що могло бути закодовано в SQL за годину. Знання SQL дуже цінні для кожного, хто пише програми, які використовують реляційну базу даних.

Навички SQL - це обов'язково вміння мати ІТ сьогодні. LINQ - це лише технологія Microsoft. Використання SQL виходить за межі розробки додатків для Інтернету та клієнтів / серверів. Ви не можете моделювати бази даних та робити ETL, якщо вам не дуже добре з SQL. Можливо, вам не знадобиться опановувати діалекти SQL, які використовуються в ORACLE та SQL Server для їх продуктів Data Warehous, але вам слід знати стандартний SQL. Основи SQL прості, для початку роботи є багато матеріалів.

Якщо ви взаємодієте з базою даних SQL, ви повинні розуміти SQL, який створює ORM. Ви повинні розуміти поняття, притаманні базам даних SQL, і ви повинні розуміти, що ваш ORM не може зробити для вас. ORM полегшують життя (і так, я думаю, що робота без одного в багатьох випадках кваліфікує вас як динозавра), але вони є інструментами (для абстрактних речей, які ви знаєте), а не милицями (щоб не допустити до навчання).

Якщо ви відмовляєтеся вивчати SQL, то у вас немає жодного бізнесу, який би торкався баз даних SQL, з ORM або без нього, і вам слід знайти інший тип роботи.

Я визнаю, що я шанувальник жорстокої боротьби з ОРМ і проповідував переваги ORM протягом багатьох років і мав багато сказати про те, чому ORM перемагає SQL.

АЛЕ ...

Я маю визнати, що SQL повністю і вкрай необхідний в реальному світі, і кожен розробник повинен добре розуміти SQL.

Програми SQL майже швидші за ORM майже у всіх випадках. Незважаючи на те, що ви можете оптимістично виводити ORM у більшості випадків, це також змушує його наблизитися до проектів SQL.

Іноді для отримання потрібного результату вам потрібен важкий SQL, і ці запити монстрів легше і швидше створювати в програмах SQL.

Всього два мої шматочки.

Прийде час, коли вам доведеться оптимізувати щось складне, що створює ORM. У цей момент у вас, як правило, є надзвичайно складний запит, який потрібно зламати. Якщо ви ніколи не вивчали основ, як можна розраховувати почати вивчати SQL за допомогою вдосконалених матеріалів? Ви не зрозумієте достатньо, щоб навіть почати. ОРМ в руках людини, яка розуміє SQL - хороший інструмент. ORM в руках того, хто взагалі не знає SQL - катастрофа, яка чекає, що станеться.

Однією з причин, чому SQL має вирішальне значення для розуміння баз даних, є те, що програмісти прикладних програм, як правило, не думають з точки зору наборів даних. Але єдиний спосіб роботи баз даних взагалі ефективно - це набори. Вам потрібно навчитися мислити наборами, перш ніж ви навіть намагатиметесь використовувати ORM.

Частіше я виявляю, що вручну вимушує запити в рамках ORM. І хоча у більшості є власна мова запитів, усі вони надихаються sql, код перетворюється на sql, і вам потрібно зрозуміти, що відбувається не так, читаючи цей sql, коли (не, якщо, коли) справи йдуть не так або погано працюють.
Тож навіть якщо ви не пишете sql безпосередньо, розуміючи його поза базовим рівнем (хоча вам, ймовірно, не потрібно буде вивчати речі щодо написання збережених процедур, тригерів тощо), якщо все, що ви збираєтеся робити, це отримати доступ до баз даних) повинна знати мову достатньо, щоб зрозуміти згенерований код і налаштувати його за потребою.

Перш ніж я розповім про це, спочатку невелике вступ; Я люблю ORM. І я ненавиджу SQL. Я люблю ORM, тому що вони приховують непривітний користувач безлад, який є SQL, і забезпечують приємний інтегрований мовами спосіб роботи з базою даних.

Однак я повинен визнати, що SQL має багато переваг, причому більший - точність. Я можу в значній мірі сперечатися про складність запиту SQL без детального знання базової схеми бази даних, просто провівши запит. Тому, коли я використовую SQL, я завжди насторожений, і завжди маю інтуїцію щодо того, куди спрямовується складність компонента.

З іншого боку, використовуючи ORM, я настільки переповнений простотою інтеграції баз даних, що я буквально забуваю, що навіть є база даних. Це мене кілька разів накручувало. Багато разів у минулому я закликав невинно виглядають методи ORM, які за лаштунками викликають масивні та страшні бази даних, що руйнують продуктивність.

Ось чому для мене правда десь посеред. Я люблю використовувати ORM, і я буду продовжувати це робити, але я повинен бути більш уважним і завжди вивчати наслідки (на рівні SQL) будь-якого виклику методу ORM. Знання наслідків шару абстракції є чистим золотом у цій справі, і виправдати використання абстракції. Все інше - це як стріляти себе на ногу.

Якщо все, що вам коли-небудь потрібно робити, це взаємодія з базою даних, хоча додаток, який ви будуєте, вам, мабуть, це не потрібно. У деяких менших компаніях або командах розробників вам може знадобитися підтримка. Набагато простіше підключитися до бази даних клієнта і запустити кілька заяв sql, щоб побачити, що відбувається з їх даними.

Навіть з хорошим, зрілим ORM ви неминуче зіткнетеся з ситуаціями, коли його випромінює якийсь неефективний SQL, і це полегшить ваше життя, якщо ви зможете збагнути те, що відбувається в створеному SQL. Це означає, що якщо ви дуже добре володієте ORM і знаєте, як використовувати профайлер для вашого вибору БД, ви можете досить легко "підробити, поки ви це зробите".

Відповідь на всі ці типи запитань ("чи потрібно мені знати X?") - "вивчіть її в перший раз, коли вона вам потрібна, якщо вона вам коли-небудь знадобиться".

Хоча важливо не потрапляти в пастку робити менш ефективно, тому що ви не знаєте або не бажаєте навчитися ефективному їх виконанню.

Наприклад, у цьому конкретному випадку, що ви робите, якщо розумієте, що у вашій програмі сталася помилка, яка спричиняла, що PostCountполе вашої таблиці користувачів часом неточно.

Ви виправляєте помилку, і тепер вам доведеться оновити PostCount для всіх користувачів. Як ви це робите?

Якщо ви пишете невеликий сценарій, використовуючи ORM, щоб це зробити, то ви дуже неефективні; буде виконаний дуже простий SQL-запит.

Оскільки ці ситуації досить поширені, я боюся, що ви потрапили в описану вище пастку!

Так, вам все ще потрібен SQL.

Не стрибайте з припущенням, що щось "старе" якимось чином не варте розгляду. Так звані "застарілі" технології - це ті, які все ще існують, витримавши випробування часом. Ми не називаємо комп’ютери Ванга "спадщиною", вони вийшли з ладу і пішли.

Якщо ви запитаєте мене, чи не турбує мене те, що мій банк, ймовірно, використовує COBOL в мейнфреймі, або IBM i? Абсолютлі ні. Це тверді породи, перевірені та справжні технології. Здогадаєтеся, вони в основному використовують DB2 SQL. Я набагато щасливіше довіряю свої гроші там, ніж програмному забезпеченню, розробленому модною мовою місяця.

Динозаври протрималися на цій землі набагато довше, ніж ми люди. А якщо ви читаєте Парк Юрасику (так, книги кращі, ніж фільми), то я запитаю вас, чи справді ви хочете зіткнутися зі зграєю гіпер-розумних велоцирапторів чи з собачим Т-Рексом, який ніколи не здається? Не скупіться, недооцінюючи "динозаврів". ;-)

Крім ігор та (в основному статистичних) досліджень, з якими я не маю досвіду, здається, що доступ до бази даних та операції є однією з небагатьох областей, де неправильні рішення призводять до дуже великих результатів. Я впевнений у більш потужних абстракціях баз даних щодо коду, і вважаю linq, який пов'язує операції з базою даних з мовою програмування, надаючи всі інструменти мови (перевірка типу, перевірка синтаксису, всі речі, які вам подобаються ваша мова програмування), але все-таки даючи вам багато сил, щоб робити те, що ви хочете, абсолютно приголомшливо. На жаль, це все ще не завжди працює. Це означає, що якщо рівень абстрагування неправильно оптимізується, і ви можете чекати секунд замість мікросекунд або хвилин замість секунд для свого результату. Оскільки це дуже помітні часи, вам доведеться їх оптимізувати, або ваша програма не працює ": продуктивність стає найбільшою проблемою вашої програми. Це означає, що вам потрібно наблизитися до металу та оптимізувати руку.

Коли ми доходимо до того, що маніпулювання великими наборами даних займає, наприклад, 3 мс при руці, і 100 мс, коли ви дозволяєте шару абстракції зробити це за вас, будь-якими способами, нехай шар абстракції обробляє це за вас, тому що ви можете бути в 30 разів повільніше, але ви все ще (мабуть, для більшості застосунків) досить швидкі. Реальність ситуації полягає в тому, що, коли ви дивитесь на оптимізовані рішення, де у вас є час реакції 200 мс, і коли шар абстракції обробляє це за вас, алгоритм приймає "лише" 10-кратний удар, у вас є 2 секунди затримки, і тоді ви піклуєтесь про багато, тому що йде не від того, що швидко, до болісно повільного. Побачивши, що рішення реляційних баз даних не дуже масштабні, Я не думаю, що це вирішиться через два-три роки. Це означає, що вам доведеться ще досить довго спускатися до чистого металу, коли мова заходить про більші бази даних, або ваш додаток буде настільки повільним, що він не може протистояти конкурентам.