Чому взагалі працюють реляційні бази даних, враховуючи теоретичну експоненціальну складність пошуку відповідей (за розміром запиту)?

Здається, відомо, що для пошуку відповіді на запит по реляційній базі даних потрібен час , і не можна позбутися від показника.$Q$$D$| Q $|D|^{|Q|}$$|Q|$

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

Це лише питання про те, що звичайні запити взагалі не є великими в реальних програмах? (Тоді цікаво дізнатися, який звичайний розмір запитів, що задаються реляційним системам баз даних, і який "максимальний" розмір запитів, на які, як очікується, ефективно відповідає система БД на практиці .)

Примітки до показникане `знімний '$|Q|$

Щоб показати, що показникне є знімним, можна скористатися запитом, запитуючи, чи існує клік розміру у графіку, заданому базою даних. Перевірити наявність графіка -clique є проблемою, що не стосується NP. Більше того, він не є фіксованим параметром, який можна відстежувати, з параметром . Деталі можна знайти, наприклад, у Лібкіна, Л.: Елементи теорії кінцевої моделі. Springer (2004) або Papadimitriou, CH, Yannakakis, M .: Про складність запитів до бази даних. J. Comput. Сист. Наук. 58 (3), 407–427 (1999)n n $|Q|$$n$$n$$n$

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

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

Даніель Маркс нещодавно представив документ STOC 2010 про субмодулярну ширину, повна версія якого містить хороший підсумок різних понять про ширину та те, як формулювання CSP стосується формалізму бази даних (цього не вистачає в конференційній версії).

• Даніель Маркс, властивості відстежуваного гіперграфа для задоволення обмежень та кон'юнктивних запитів , 2010. arxiv: 0911.0801

Це не є повною відповіддю, оскільки вона не стосується "типової" складності запитів до баз даних, але навіть при гіршому випадку аналізу є легкі запити.

Можна використовувати запити Q_n, щоб перевірити, чи графік, представлений у вигляді бази даних, містить кліку з n елементами. Перевірити, чи має графіка кліка, є проблемою, що не стосується NP. Більше того, це не фіксований параметр, який можна відстежувати, з параметром n (що означає D ^ n).

Ще один спосіб відповісти на це запитання: "вони не роблять!"

Якщо ви даєте типову реалізацію СУБД запит, що містить дуже велику кількість приєднань, він навіть не пройде фазу планування / оптимізації (не кажучи вже про оцінку), навіть якщо запит ациклічний або іншим чином має дуже просту структуру, наприклад Андраш натякає на вище.

Але для "типових" завантажень СУБД такі запити, схоже, не виникають.

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

Приєднання є лише квадратичними щодо стосунків між багатьма. Вони відносно рідкісні: на практиці більшість зв'язків і з'єднань є 1-множиною, тому вони забирають лінійний час, якщо визначені індекси / ключі. Запити з кількома об'єднаннями багато-до-багатьох є серйозною проблемою.