Чи все ж є потреба в написанні SQL?

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

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

• Вам зручніше писати SQL для запиту даних, ніж ви пишете процедурний код.
• Ваш ORM, хоча і красиво дивитися, генерує жахливо повільний SQL в якійсь критичній області.
• Вам потрібно скористатися функціоналом, що піддається вашим RDBMS, який не може / не може бути доступний через ваш ORM.
• Кожен раз, коли ви набираєте SELECT * FROM..., Бог вбиває кошеня. А ви ненавидите кошенят.
• Ви не використовуєте ORM, OOP або сучасну мову.

Написання складних SQL

ORM чудово підходять для базових речей. Однак для складних ситуацій вам доведеться писати SQL.

Отже, коротше кажучи, існує безперечно потреба в SQL, і він завжди буде таким.

• Перегляди
• Тригери
• Обмеження
• Пакети (SSIS, DTS тощо)
• У будь-який час вам потрібно точно контролювати потік виконання

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

Звичайно:

• Зазвичай ORM інкапсулює багато, але врешті-решт, ви повинні знати, що відбувається за лаштунками. Це має вирішальне значення для продуктивності та масштабованості. Хоча всередині програми я не пишу стільки SQL, але приблизно знаю, як виглядає SQL або DDL.
• Прямий SQL часто приємно писати запити лише для читання. Набагато простіше, як сформулювати його в мові запиту ORM, і ви також можете обмежити набір результатів (наприклад, 'select id from .....').
• ORM взагалі не повинен тримати вас подалі від SQL. Я дуже часто використовую SQL для спеціальних запитів безпосередньо на DB-клієнті (наприклад, mysql-client). Це дає дуже гарний рівномірний інтерфейс та групування функціональних можливостей.

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

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

На практиці я ніколи не бачив проекту чистого ORM, який не потребував принаймні SQL для запиту бази даних для остаточної перевірки.

ORM - це інструмент у вікні інструментів програмістів. У них є свої проблеми. Деякі приклади:

• Неможливо керувати sql
• Страждає від проблеми n + 1

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

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

Також ORM здебільшого не корисні для процесів BI або ETL. Вони також не корисні для запитів адміністратора бази даних або для пошуку інформації в таблицях аудиту та скасування певного набору змін у базі даних. Є багато речей, які все ще найбільш ефективно робляться з SQL. Додаток, який запитує базу даних, є невеликою частиною того, що потрібно для запиту в середовищі Enterprise.

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

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

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

Також, використовуючи базу даних типу Oracle з дуже насиченою та потужною мовою процедур, ви можете зробити багато, навіть коли не потрібна «програма». PL / SQL на Oracle у потрібних руках дуже швидкий і ефективний.

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

Це все ще потрібно для написання тригерів і збережених процедур. Наразі збережені процедури, можливо, не прихильні, але в деяких ситуаціях вони все ще дуже корисні. SQL також може знадобитися для деяких особливо волохатих кількох столів.

Так, ви можете уникати написання SQL. Але ви натомість напишете HQL замість цього (або Linq, або DQL ...)!

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

(Але щодо проблеми N + 1: це пов'язано з ледачим завантаженням, і більшість інструментів ORM мають певний спосіб вимагати завантаження, таким чином уникаючи цієї конкретної проблеми.)

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

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

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

У інший час вам може не знадобитися SQL для ваших CRUD-матеріалів, але в SQL є набагато більше, ніж прості запити SELECT, INSERT, UPDATE та основні JOIN. Ви можете робити дуже розумні речі з цим, і хоча ви не можете ними користуватися часто, корисно знати, що вони є.

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

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

Для створення великомасштабних веб-додатків це абсолютно непотрібно, і це може зробити речі набагато більш напруженими та витрачати час, ніж потрібно. Причиною цього є те, що будь-яке масштабне додаток повинно використовувати шар стійкості пам'яті (в оперативній пам'яті), який повинен бути частиною кешування пам'яті БД, яка часто використовується.

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

Складність та кількість записуючого SQL не є достатнім для того, щоб зробити підключення рамки ORM розумним.

(Я пишу SQL, можливо, раз на місяць, якщо)

Я стикався з багатьма великими корпусами з DBA, які активно бояться розробників, використовуючи засоби ORM.

Це DBA, які беруть участь у налаштуваннях та виконанні.

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

Крім того, інструментами ORM можна жорстоко зловживати і створювати такі ж погані Sql, як і самостійно писати Sql.

Один biggie - міграція DDL та бази даних. Іноді вам потрібно вручну зшити цей матеріал, щоб оновити речі, не порушуючи наявних даних.