#Бази Даних

Потрапила на очі фраза “хто ж пише SQL, коли вже н-цять років існують ORM?” Хотілося прокоментувати. Тут є цікавий розподіл.

Головна міць реляційних баз даних — це, власне, ота реляційна модель, яку ніхто (включаючи мене) досконало не розуміє. (Пропоную задати собі питання — про яке відношення йдеться?) Але суть в тому, що ми можемо обʼєднувати розрізнені факти, щоб отримати сукупний результат.

Наразі існує достатньо нереляційних баз, щоб побачити, що ця можливість не є універсальною. От в OpenSearch все, що ми можемо — це шукати документи за критеріями та агрегувати. Все інше — дорого (та реалізується тим самим пошуком.) У CoreData немає COUNT. В DynamoDB взагалі кожний запит треба задумати наперед.

А у реляційній базі всі дані доступні для поєднання. Роби з ними що хочеш. Причому поєднання ще й буде ефективним — це і є основна пропозиція будь-якої реляційної бази. Та хто працює з аналітикою, бачив ті кілометрові запити на SQL, які генерують звіт з двадцяти таблиць з усіх околиць компанії. (Користуюся нагодою прорекламувати наш продукт Coupler, який допомагає зібрати ті дані з розрізнених джерел.)

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

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

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

• Навчитися робити розрізи. Розріз (View) - це фактично збережений запит. Ззовні виглядає як таблиця. Якщо у вас складний багатоповерховий запит, можна його декомпонувати — винести з нього розрізи, та тоді кожний етап буде легше зрозуміти окремо.

• Навчитися використати CTE CTE - Common Table Expressions (“спільні оголошення таблиць”, певно) - як розріз, але оголошений в межах поточного запиту. Це перший крок до структурованих запитів. Спочатку через WITH оголошуєш допоміжні запити, а потім в головному запиті використовуєш як звичайні таблиці. Чомусь вважається просунутою технікою SQL, хоча насправді в CTE немає нічого складного.

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

• Тести! А чом би й ні? Побудували дані, перевірили результат. Звісно, легше це робити, коли не потрібно кожний стовпчик заповнювати явно. Тому в Go мені з цим важко, зате в Ruby - легко. Сьогодні дізнався, що й тести безпосередньо для СКБД теж існують — наприклад, pgTAP для PostgreSQL.