таблиця предметів, яка (потенційно) містить десятки мільйонів записів.
Це насправді не так вже й багато, враховуючи те, з чим SQL Server може ефективно впоратися. Звичайно, я пам’ятаю одну з моїх попередніх робіт, де одна з найбільших таблиць (система з одним примірником) мала 2 мільйони рядків, і це було найбільше, з чим я коли-небудь мав справу. Тоді в наступному завданні було 17 виробничих екземплярів, де деякі таблиці мали сотні мільйонів рядків, і всі вони були об'єднані в сховище даних з кількома таблицями фактів, що мають понад 1 мільярд рядків. Не зрозумійте мене неправильно, я не знущаюся з десятків мільйонів рядків, я лише підкреслюю, що за допомогою хорошої моделі даних та належного індексування (та обслуговування індексу) SQL Server може впоратися з багатьма .
До 50% елементів можуть бути "не схвалено" в будь-який момент.
Хм. Це не звучить правильно. Швидкість "схвалення" записів буде вдвічі меншою за швидкість отримання нових записів? На кожні 2 нові записи лише 1 буде "затверджено"? У вашому прикладі 2 мільйони рядків та 1 мільйон у кожному для "затверджених" та "неприйнятих", через кілька років із ще 10 мільйонами записів ви очікуєте по 6 мільйонів у кожному "затвердженому" та "не затвердженому"? Або це так, що 1 мільйон "не затверджених" залишиться дещо постійним, так що з 10 мільйонів нових записів буде 11 мільйонів "затверджених" і ще 1 мільйон "не затверджених"?
Записи можуть стати "затвердженими", але не навпаки.
Це так і сьогодні , але все змінюється з часом, і тому завжди існує можливість, що бізнес міг би вирішити, щоб дозволити "не схвалювати" або, можливо, якийсь інший статус, наприклад "заархівований" тощо.
Отже, давайте розглянемо вибір:
Прапор (або, можливо, навіть TINYINT"статус")
- Трохи повільніше для запитів кожного статусу
- Більш гнучка з часом / легко включити зміни, такі як третій стан (наприклад, "Заархівовано") лише з новим значенням статусу пошуку. Немає нової таблиці (обов'язково), якийсь новий код, лише якийсь код оновлений.
- Менше роботи (тобто код, тестування тощо) та менше місця для оновлення помилок у одному
TINYINTстовпчику
- Менш складні = менші витрати на обслуговування з часом, коротший час навчання для нових працівників
- (можливо) Менший вплив на Журнал транзакцій у міру оновлення однієї таблиці
- Просто потрібна таблиця пошуку для "RecordStatus" і FK між двома таблицями.
Дві окремі таблиці (одна для «затверджених», одна для «не затверджених»)
- Трохи швидше для запитів кожного статусу
- Менш гнучкими з часом / важче включити зміни, такі як третій стан (наприклад, "Заархівовано"); новий стан зажадає, швидше за все, ще одну таблицю і, безумовно, новий і оновлений код.
- Більше роботи (тобто код, тестування тощо) та більше місця для переміщення записів про помилки з таблиці "Не схвалено" до таблиці "Затверджено"
- Складніше = більші витрати на обслуговування з часом, довший час навчання нових працівників
- (можливо) Більший вплив на Журнал транзакцій, коли одна таблиця видалена, а одна вставлена
- Не потрібно хвилюватися з приводу " відновлення ідентифікатора елемента ": У несанкціонованій таблиці є стовпець ідентифікатора, який є
IDENTITYстовпцем, а затверджена таблиця має стовпчик ідентифікатора, який не є IDENTITY(як там він не потрібен). Значення ідентифікаторів залишаються послідовними при переміщенні запису між таблицями.
Особисто я схиляюся до єдиної таблиці зі StatusIDстовпцем для початку. Використання двох таблиць виглядає як надто складна, передчасна оптимізація. Цей тип оптимізації можна обговорити, якщо / коли кількість записів становить декілька сотень мільйонів, а індексація не забезпечує жодних прибутків.