“Велика база даних” - справді туманне поняття. У відповідях на це питання вже є дуже різні відповіді та думки. Деякі підходи до визначення „малих”, „середніх” та „великих” баз даних можуть мати більше сенсу, ніж інші, АЛЕ ТО, у певний момент я вважаю, що кожне визначення є правильним, правдивим та дійсним.
Деякі визначення мають більше сенсу, ніж інші, оскільки вони зосереджуються на різних аспектах, важливих для проектування, програмування, використання, обслуговування та адміністрування бази даних, і ці різні аспекти є тим, що насправді має значення для придатної для використання бази даних. Просто трапляється, що на всі ці аспекти впливає туманна концепція «Розмір бази даних».
Отже, чи означає це, що неважливо, чи зможете ви визначити, чи є певна база даних великою чи ні?
Звичайно, ні. Це означає, що ви будете застосовувати концепцію по-різному, оцінюючи різні дизайнерські / оперативні / адміністративні аспекти своєї бази даних. Це також означає, що кожного разу ця концепція буде туманною.
Як приклад: на стратегію індексу бази даних (аспект дизайну бази даних) впливає кількість записів для кожної таблиці (міра “розміру”), розмір запису вмножений на кількість записів (інша міра “розміру”) та запит проти . Співвідношення операцій створення / оновлення / видалення (аспект використання бази даних).
Час відповіді на запит кращий, якщо індекси використовуються для таблиць із великою кількістю записів. Залежно від природи ваших пропозицій WHERE, ORDER BY та агрегування записів, вам може знадобитися кілька індексів для певних таблиць.
Операції створення, оновлення та видалення впливають негативно зі збільшенням кількості індексів у таблицях, що зазнали впливу. Більше індексів для зазначеної таблиці означає більше змін, які повинна виконувати СУБД, витрачаючи більше часу та більше ресурсів на застосування цих змін.
Крім того, якщо ваша СУБД витрачає більше часу на застосування цих змін, то блокування зберігаються і довший час, впливаючи на час відгуку інших запитів, що надсилаються в систему одночасно.
Отже, як ви збалансуєте кількість та дизайн своїх індексів? Як ви дізнаєтесь, чи потрібен вам додатковий індекс, і якщо, додавши цей індекс, ви не матимете значного негативного впливу на час відгуку запиту? Відповідь: Ви перевіряєте та профілюєте базу даних відповідно до цільового навантаження відповідно до ваших вимог до навантаження / продуктивності та аналізуєте дані профілювання, щоб виявити, чи потрібні подальші оптимізації / перепроектування / індекси.
Різні стратегії індексу потрібні для різних запитів проти. Створення / оновлення / видалення коефіцієнтів операцій. Якщо у Вашій Базі даних значне навантаження, але вона рідко оновлюється, продуктивність загальної програми буде кращою, якщо Ви додасте кожен індекс, що покращує час відгуку на запит. З іншого боку, якщо ваша база даних постійно оновлюється, але немає великих операцій запиту, то продуктивність буде кращою, якщо ви використовуєте менше індексів.
Звичайно, є й інші аспекти: дизайн схеми бази даних, стратегія зберігання, мережевий дизайн, стратегія резервного копіювання, збережені процедури / тригери / тощо. програмування, програмування додатків (проти бази даних) тощо. На всі ці аспекти по-різному впливають різні поняття "розмір" (розмір запису, кількість записів, розмір індексу, кількість індексів, дизайн схеми, розмір сховища тощо).
Я хотів би мати більше часу, оскільки ця тема захоплює. Сподіваюся, цей невеликий внесок послужить вам відправною точкою у цьому захоплюючому світі SQL.