Процедурні розширення

Складність роботи з ієрархічними структурами

Відступи від стандартів

Складність

Невідповідність реляційної моделі даних

Недоліки стандартів SQL

Декларативність

Наявність стандартів

Наявність стандартів і набору тестів для виявлення сумісності і відповідності конкретній реалізації SQL загальноприйнятому стандарту тільки сприяє «стабілізації» мови. Правда, варто звернути увагу, що сам по собі стандарт місцями занадто формалізований і роздутий в розмірах, наприклад, Core-частину стандарту SQL:2003 включає понад 1300 сторінок тексту.

За допомогою SQL програміст описує тільки те, які дані потрібно витягнути або модифікувати. Те, яким чином це зробити, вирішує СУБД безпосередньо при обробці SQL-запиту. Проте не варто думати, що це повністю універсальний принцип — програміст описує набір даних для вибірки або модифікації, проте йому при цьому корисно уявляти, як СУБД розбиратиме текст його запиту. Особливо критичні такі моменти стають при роботі з великими базами даних і зі складними запитами — чим складніше сконструйований запит, тим більше він допускає варіантів написання, різних за швидкістю виконання, але тих самих за набором даних.

Творець реляційної моделі даних Едгар Кодд, Крістофер Дейт та їхні прихильники указують на те, що SQL не є істинно реляційною мовою. Зокрема вони указують на такі проблеми SQL^[3]:

- Рядки, що повторюються

- Невизначені значення (null)

- Явна вказівка порядку стовпчиків зліва направо

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

- Використання покажчиків

- Висока надлишковість

У опублікованому Крістофером Дейтом і Г'ю Дарвеном Третьому Маніфесті вони висловлюють принципи СУБД наступного покоління і пропонують мову Tutorial D, яка є достовірно реляційною.

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

Незважаючи на наявність міжнародного стандарту ANSI SQL-92, багато компаній, СУБД (наприклад, Oracle, Sybase, Microsoft, MySQL), що займаються розробкою, вносять зміни до мови SQL, вживаної в розроблених ними СУБД, тим самим відступаючи від стандарту. Таким чином з'являються специфічні для кожної конкретної СУБД діалекти мови SQL.

Раніше SQL не пропонував стандартного способу маніпуляції деревовидними структурами. Деякі постачальники СУБД пропонували свої рішення. Наприклад, Oracle використовує вираз CONNECT BY.

Оскільки SQL не є мовою програмування (тобто не надає засобів для автоматизації операцій з даними), введені різними виробниками розширення стосувалися в першу чергу процедурних розширень. Це збережені процедури (англ. stored procedures) і процедурні мови-«надбудови». Практично в кожній СУБД застосовується своя процедурна мова. Подібні мови для найпопулярніших СУБД приведені в такій таблиці:

СУБД	Коротка назва	Розшифровка
Borland InterBase/ Firebird	PSQL	Procedural SQL
IBM DB2	SQL PL	SQL Procedural Language (розширює SQL/PSM)
Microsoft SQL Server/ Sybase ASE	Transact-SQL	Transact-SQL
MySQL	SQL/PSM	SQL/Persistent Stored Module
Oracle	PL/SQL	Procedural Language/SQL (заснований на мові Ada)
PostgreSQL	PL/pgSQL	Procedural Language/PostgreSQL Structured Query Language (схожий на Oracle PL/SQL)

Читайте також:

<== попередня сторінка	\|	наступна сторінка ==>
Незалежність від конкретної СУБД	\|	Запис SQL-операторів

Не знайшли потрібну інформацію? Скористайтесь пошуком google:

Генерація сторінки за: 0.004 сек.