Які переваги використання конструкторів запитів SQL?

Чи є якісь переваги використання конструктора запитів, а не використання сирого SQL?

Напр

$q->select('*')
  ->from('posts')
  ->innerJoin('terms', 'post_id')
  ->where(...)

vs:

SELECT * FROM posts WHERE ...

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

Абстрагування написання SQL через рамкову свердловину, реферати.

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

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

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

Забудовники запитів - це моя ненависть до домашніх тварин, тому я написав власний Framework (Apeel), щоб уникнути їх використання!

Якщо ви використовуєте PDO (який я напевно рекомендую вам зробити), то з використанням введення даних обробка даних здійснюється для вас.

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

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

Час, витрачений на те, щоб впоратися з qwirks розробника запитів (потім повторне навчання, коли ви переходите на кращий), було б набагато продуктивніше витратити на навчання оптимізації вашого SQL.

У всякому разі, тому НЕ використовувати його, хоча деякі люди їх люблять.

Теоретично? Так. Гленн Нельсон зазначив, як вони вам часто допоможуть. (Якщо це хороший конструктор запитів).

На практиці? Це не завжди відповідає теорії і може насправді викликати проблеми. Припустимо, що ви використовуєте конструктор запитів проти деяких популярних СУБД, і все це дуже просто. Тоді замовник просить вас натиснути на їх СУБД, яка має деякі химерності, з якими обраний розробник запитів просто не може впоратися. (Я потрапив у цю проблему, коли мені довелося працювати зі старішою версією Pervasive.)

АЛЕ! Що ви повинні абсолютно зробити, це відокремити рівень доступу до даних і переконатися, що за потреби можна поміняти новим. Таким чином, ви можете отримати цей класний конструктор запитів із усіма можливостями, але якщо вам потрібно підключити новий, який використовує цей дивний псевдо-sql для відповідної БД.

Я думаю, що практична, щоденна користь побудови запитів - це повторне використання коду та можливість слідувати принципу DRY.

За допомогою конструктора запитів ви можете помістити повторювані частини SQL у методи. А потім використовуйте ці методи для складання складного SQL. Прикладом може бути, наприклад, пункт JOIN для повторного використання:

function joinTaskWithClient($queryBuilder) {
    $queryBuilder->join('task', 'contract', 'task.contract_id = contract.id')
                 ->join('contract', 'client', 'contract.client_id = client.id');
}

Тож використання було б:

$queryBuilder->select('client.name')
             ->from('client')
             ->where('task.id=:task')->setParameter('task', 42);
joinTaskWithClient($queryBuilder);

Як ви можете зауважити - за допомогою конструктора запитів ви можете додавати частини SQL у будь-якому порядку (наприклад, ПРИЄДНАЙТЕ частину після того, де БЕЗ), на відміну від випадку, коли ви збираєте рядок SQL вручну. Крім того, ви можете прочитати про шаблон розробника, щоб побачити його наміри та переваги.

Я погоджуюсь щодо втечі та санітарії, але цього можна досягти і без будівельника запитів. Що стосується типу БД / діалектної абстракції - це цілком теоретична та сумнівна користь, яка майже ніколи не використовується на практиці.

я надам відповідь на основі файлу readme користувальницького SQL-конструктора ( Dialect )

(простий текст випливає, видалені посилання на конкретні бібліотеки)

Вимоги

1. Підтримка декількох постачальників БД (наприклад, MySQL, PostgreSQL, SQLite, MS SQL / SQL Server, Oracle, DB2, ..)
2. Легко поширюється на нові БД (бажано через налаштування конфігурації, незалежне від впровадження)
3. Модульність та незалежність від передачі
4. Гнучкий та інтуїтивний API

Особливості

1. шаблони на основі граматики
2. спеціальна підтримка м'яких поглядів
3. db абстракція, модульність та переносимість
4. підготовлені шаблони
5. отримання даних

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

Більшість перерахованих вище функцій підтримується більшістю SQL-будівельників (хоча я не думаю, що всі перераховані підтримуються, наскільки мені відомо)

Приклади використання:

1. Платформа CMS, здатна працювати (без зміни базового коду) з декількома постачальниками БД
2. Спеціальний код програми, де постачальник БД схильний змінювати та / або схеми dB є динамічними (це означає, що багато запитів не можуть бути жорстко кодованими, але все-таки повинні бути досить абстраговані, щоб код надійний до змін)
3. Прототипування з іншою БД, ніж використовується у виробництві (зажадає дублювання бази коду принаймні для деякого коду)
4. Код програми не щільно пов'язаний з конкретним постачальником БД та / або реалізацією (навіть у межах одного постачальника БД, наприклад, різних версій постачальника БД), таким чином, є більш надійним, гнучким та модульним
5. Багато звичайних випадків запитів і отримання даних обробляються самими рамками, і зазвичай це оптимально і швидше

Нарешті, приклад використання у мене був. я будував додаток, коли основна схема БД (wordpress) була недостатньо підходяща для типу запитів даних, які потрібно було виконати, плюс деякі таблиці WP (наприклад, пости) повинні були використовуватися (тому маючи абсолютно нові таблиці для всіх додатків дані не були варіантами).

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

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

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

Подивіться, що я маю на увазі?

Досить часто деяким аргументом для цих запитів справді є якісь значення, а не константи. Зараз багато з них по суті є похідними від публікацій користувачів. Отже, існує багато можливостей для атак на ін'єкцію SQL. Тому для формування запитів по суті потрібна повна перевірка.

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

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

Використовувати такі конструктори запитів добре , але я схильний вважати, що люди, які сильно покладаються на них, як правило, не запитують DBA: "Гей, це запит, який я багато використовую, будь ласка, створіть з нього погляд".

Не зрозумійте мене неправильно.

Я думаю, що ви повинні писати запити проти переглядів, а не таблиць. Не для безпеки чи фільтрації, які є вагомими причинами, але з тієї ж причини слід кодувати проти інтерфейсів, а не проти конкретних класів: роз'єднання. Погляди схожі на "договори", так само інтерфейси є "контракти" в OOP. Ви можете змінювати основні таблиці, але поки ви змушуєте погляди показувати однаковий «контракт» програмістам, код не повинен порушуватися.

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

Я помиляюся, думаючи, що, не записуючи запити, ви не зможете виявити необхідність створення певних поглядів?

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