Розширення захоплення SQL

Згідно з Іммерманом , клас складності, пов'язаний із SQL- запитами, є саме класом безпечних запитів у $\mathsf{Q(FO(COUNT))}$ (запити першого порядку плюс оператор підрахунку): SQL фіксує безпечні запити. (Іншими словами, всі запити SQL мають складність у $\mathsf{Q(FO(COUNT))}$ , а всі проблеми - у $\mathsf{Q(FO(COUNT))}$ може бути виражений у вигляді SQL-запиту.)

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

Чи є розширення SQL (впроваджене та використовується в галузі ), яке фіксує $\mathsf{P}$ (тобто може виражати всі обчислювальні запити в многочлени та без інших)?

Я хочу мову запиту до бази даних, яка підкреслює всі три умови. Легко визначити розширення , яке буде розширити SQL і захопити . Але мої запитання полягають у тому, чи така мова має сенс з практичної точки зору, тому я хочу мову, яка використовується на практиці. Якщо це не так і немає такої мови, то я хотів би знати, чи є причина, яка робить таку мову нецікавою з практичної точки зору? Наприклад, чи запити, що виникають на практиці, зазвичай досить прості, що немає необхідності в такій мові?$\mathsf{P}$

Що стосується вашого головного питання, я рекомендую це коротке опитування Мартіна Грое.

Чи запити, які потрібні на практиці, зазвичай є досить простими, щоб не було потреби в більш сильній мові?

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

У рідкісних випадках може знадобитися більш потужна мова, я гадаю, що розробники програмного забезпечення справляються з ними за допомогою мови, якою вони пишуть додаток, а не запитів (наприклад, C ++ або java).

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

• Леонід Лібкін. Виразна потужність SQL , TCS 296 (3), 379–404. DOI: 10.1016 / S0304-3975 (02) 00736-3 ( препринт )

Це означає, що для захоплення PTIME потрібне розширення для SQL-92 і таке, яке дозволяє отриманій мові бути "не локальною".

Однак, якщо дозволити впорядковані структури та з реально обмеженою арифметикою, доведення того, що SQL-92 не може виразити доступність, означало б, що це єдиний і, отже, це буде досить складно. (Можна стверджувати, що природне лінійне впорядкування завжди існує для типів даних у SQL-92, і тому можна припустити, що базові структури впорядковані.)$\text{TC}^0 \subsetneq \text{NLOGSPACE}$

Потім пейзаж знову змінився, оскільки SQL: 1999 (SQL3) включав рекурсію. Тож SQL: 1999 здається настільки ж виразним, як логіка з фіксованою точкою з підрахунком (хоча, я думаю, деталі можуть знову бути досить складними, включаючи питання порядку). Чи зробили нові конструкції логіку більш виразною, ніж потрібно для захоплення PTIME, я не знаю, і для встановлення цього потрібно було б провести певне дослідження. Тим часом в 2003 , 2006 , 2008 роках були внесені подальші зміни та 2011 роках(будучи документами ISO, вільно доступні лише чернетки). Ці версії додали цілу низку нових функцій, у тому числі дозволяючи XQuery як "частину" SQL запитів. Я здогадуюсь, що "SQL" зараз є більш виразним, ніж потрібно для зйомки PTIME, але для кодування, необхідного для цього, можуть знадобитися великі і неприродні запити, які можуть не підтримуватися в реальних системах.

Тому я думаю, що є докази того, що не існує промислового розширення SQL, яке б точно захоплювало PTIME , відповідаючи на ваше запитання нечітко. Коротше кажучи, промислові розширення є досить потужними і, можливо, вже мають прострочений PTIME. Якщо правда, що SQL: 1999 вже досить потужний, щоб захопити принаймні PTIME, то також не ясно, що насправді означає "SQL" у вашому запитанні, оскільки потрібно було б визначити "SQL", щоб означати версію, що передує SQL: 1999 рік.

Нарешті, опитування Грое щодо пошуку логіки, що фіксує PTIME (також згадується Яномою), вказує не лише на те, що захоплення PTIME є хитромудрим, якщо ми не маємо лінійний порядок як частина мови, але і те, що доказ того, що такої логіки не може бути також маємо на увазі .$\text{P} \ne \text{NP}$

• Мартін Грое, Пошуки логіки , що фіксують ПТІМЕ, ЛІТКИ 2008, 267–271. DOI: 10,1109 / LICS.2008.11 ( препринт )

$P$$P$$P$$P$$P$

$P = NP$$P = NP$$P$$P$$NPC$

$P \ne NP$

$P = NP$

Мабуть, він, ймовірно, не існує в реальних цілях, він, безумовно, існує і є конструктивним та реалізованим. Ви можете визначити цю мову з чимось здатним імітувати машину Тьюрінга до заданої кількості одинакових кроків. IE, здатний вирішити P-повну задачу. Однак, якщо ви побудуєте таку річ, вона майже повна Тьюрінга, за винятком обмеження "з заданим числом кроків", що в мові, подібній SQL, було б дуже дивним способом обмежити її лише безпечними запитами. Ви могли б зробити це, якщо кроки є записами якоїсь таблиці, але це все ще не представляє нічого корисного для практичних цілей.