• Гідрологія і Гідрометрія
• Господарське право
• Економіка будівництва
• Економіка природокористування
• Економічна теорія
• Земельне право
• Історія України
• Кримінально виконавче право
• Медична радіологія
• Методи аналізу
• Міжнародне приватне право
• Міжнародний маркетинг
• Основи екології
• Предмет Політологія
• Соціальне страхування
• Технічні засоби організації дорожнього руху
• Товарознавство продовольчих товарів

Незалежність від конкретної СУБД

Переваги стандартів SQL

Питання сумісності

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

До 1996 року питаннями відповідності комерційних реалізацій SQL стандарту займався в основному інститут NIST, який і встановлював рівень відповідності стандарту. Але пізній підрозділ, що займався СУБД, був розформований, і в цей час всі зусилля з перевірки СУБД на відповідність стандарту лягають на її виробника.

Вперше поняття «Рівня відповідності» було запропоноване в стандарті SQL-92. А саме, ANSI і NIST визначали чотири рівні відповідності реалізації цьому стандарту:

§ Entry (базовий)

§ Transitional (перехідний) — перевірку на відповідність цьому рівню проводив тільки інститут NIST

§ Intermediate (проміжний)

§ Full (повний)

Легко можна зрозуміти, що кожен подальший рівень відповідності свідомо мав на увазі відповідність попередньому рівню. Далі, згідно з цими рівнями стандартів будь-яка СУБД, яка відповідала рівню Entry, могла заявляти себе як «SQL-92 відповідна», хоча насправді переносимість і відповідність стандарту обмежувалося набором можливостей, що входять у цей рівень.

''Положення'' змінилося з введенням стандарту SQL:1999. Відтепер стандарт придбав модульну структуру — основна частина стандарту була винесена в розділ «SQL/Foundation», всі інші були виведені в окремі модулі. Відповідно, залишився тільки один рівень сумісності — Core, що означало підтримку цієї основної частини. Підтримка решти можливостей залишена на розсуд виробників СУБД. Аналогічне положення мало місце і з подальшими версіями стандарту.

Незважаючи на наявність діалектів і відмінностей в синтаксисі, в більшості своїй тексти SQL-запитів, що містять, DDL і DML, можуть бути досить легко перенесені з однієї СУБД в іншу. Існують системи, розробники яких спочатку закладалися на застосування щонайменше кількох СУБД (наприклад: система електронного документообігу Documentum може працювати як з Oracle, так і з Microsoft SQL Server та IBM DB2). Природно, що при застосуванні деяких специфічних для реалізації можливостей такої переносимості добитися вже дуже важко.

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

1. II. Визначення мети запровадження конкретної ВЕЗ з ураху­ванням її виду.
2. Боротьба за возз’єднання Української держави, за незалежність у 60- 80-х роках XVII ст.
3. Боротьба за возз’єднання Української держави, за незалежність у 60-80-х роках XVII ст.
4. Вибір конкретної різновидності товару-представника.
5. Виникнення суб'єктивних прав і юридичних обов'язків — перехід від загальних приписів правових норм до конкретної моделі поведінки конкретних господарюючих суб'єктів.
6. Геьбман Іван Мазепа і його спроба відновити державну незалежність України
7. Історичне значення та уроки боротьби укр. народу за незалежність.
8. Конструктивні особливості антен залежать від конкретної тактичної задачі, що її розв'язує користувач каналу зв'язку.
9. Культурна ідентифікація – це самовідчуття людини в середині конкретної культури.
10. Надання стратегії конкретної форми.
11. Незалежність аудиторів

Переглядів: 773