Чи має це коли-небудь сенс, щоб програма застосувала цілісність бази даних замість того, щоб мати сторонні ключі, перевірити обмеження тощо?
Скільки покращення продуктивності можна очікувати за неприйняття цілісності бази даних за допомогою внутрішніх інструментів бази даних?
Відповіді:
Правду кажучи, ви не тільки не побачите великої втрати продуктивності від наявності зовнішніх ключових обмежень у базі даних, але й побачите підвищення продуктивності. Оптимізатор запитів SQL Server побудований на основі концепції первинних і невід'ємних ключів, а також інших типів обмежень даних. Якщо вони встановлені та застосовані, оптимізатор може скористатися ними, щоб покращити ефективність роботи. Ось допис у блозі з простим прикладом, який показує його в дії.
Якщо ви перебуваєте в кращому випадку, коли ви справді маєте більше вставок, ніж читає (а оновлення та видалення потребують зчитування, тому вони, як правило, додаються до кількості прочитаних), можливо, має сенс видалити обмеження з даних для продуктивності, можливо . Але оскільки переважна більшість баз даних орієнтована на читання, ви жертвуєте продуктивністю, не підвищуючи її.
І нічого з цього не згадує той факт, що цілісність даних краще обробляється в базі даних, оскільки її потрібно створити лише один раз там, ніби ви виконуєте всю роботу в коді, можливо, вам доведеться робити це кілька разів для декількох додатків (якщо ви не проектуєте ваш рівень доступу до даних обережно і вимагає, щоб кожен додаток отримував доступ до db, щоб пройти той самий рівень).
Якщо ви використовуєте реляційну систему баз даних, я кажу, чому б не реально її використовувати. Якщо вам не потрібні реляційні дані, перейдіть з Hadoop або чимось іншим.
Дуже багато розробників додатків так вважають.
Коли ви спокушаєтеся делегувати цілісність даних коду програми, подумайте, "Кожен програміст і кожна програма, яка потрапляє в цю базу даних відтепер і до кінця часу, повинна кожного разу отримувати її абсолютно правильно".
Які шанси?
Навіть якщо приріст продуктивності є незначним, порівняно із поверненням референтної цілісності та узагальненої цілісності даних.
Давно минули дні, коли база даних є німим сховищем даних. Використовуйте потужність, яку пропонує RDBMS.
Підвищення продуктивності - це не все, особливо в такому невеликому масштабі, як це. Але коли ви дізнаєтесь, що у вас є нібито відносини із зовнішнім ключем, які має застосувати ваша програма, і виявиться, що це не первинний ключ у таблиці довідок, тоді ви будете дуже мало піклуватися про підвищення продуктивності (якщо такий є, я можу не говорять про специфіку цього).
Звичайна практика скидати обмеження (сторонні ключі, перевірити і т. Д.) Та індекси, якщо ви робите достатньо велике завантаження даних, а потім знову ввімкнути / реалізувати обмеження та індекси. Ця перевірка має часову вартість. Це припускає, що ви не можете використовувати синтаксис основного завантаження, характерний для бази даних (включаючи мінімізацію журналу).
Неможливо сказати, на скільки очікується збільшення продуктивності - кожна ситуація є унікальною (типи даних, дизайн тощо). Єдиний спосіб по-справжньому знати - це протестувати.
Є кілька разів, коли обмеження перешкоджають:
Коли вам потрібно використовувати спадкове використання однієї таблиці (STI). Уявіть, що ви продаєте як приватним особам, так і організаціям. Вам знадобиться одна таблиця "Вечірка", рядок якої є окремою особою або органом. STI означає, що вам потрібні деякі нульові поля, які не повинні бути нульовими. Спадкове наслідування класів вирішує це, але для деяких ОРМ це складніше. Ruby's ActiveRecord підтримує лише STI, наприклад.
Коли вам потрібно підтримати Чернетні версії об'єкта, це може бути не повністю дійсним. Ви можете зберігати чернетку як json, але тоді важче повторно використовувати той самий ідентифікатор на клієнті - уявіть, що він збережений з id = 5, відредагований як недійсний і автоматично збережений як draftid = 99. У цьому випадку всі ваші поля, мабуть, повинні бути нульовими.