таблица элементов, которая (потенциально) будет содержать десятки миллионов записей.
Это на самом деле не так уж много, учитывая, что 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колонкой для начала. Использование двух таблиц кажется слишком сложной, преждевременной оптимизацией. Этот тип оптимизации можно обсудить, если / когда число записей составляет несколько сотен миллионов, и индексация не обеспечивает какого-либо увеличения производительности.