Огромная проблема с дизайном таблицы базы данных

Question

В моем дизайне БД я столкнулся с проблемой. Мое приложение состоит из рабочего процесса на определенный вид СМИ, который имеет 6 этапов следующим образом:

1. Ресурсы
2. глотают
3. Обзор
4. видеоРемонт
5. Листинг
6. резервного копирования

Поскольку на всех этапах тип данных, добавляемых (или обновляемых) к таблице, является то же самое, но только их имена меняются, например, в глотать мы следующие колонки

CaptureSup_Name, Assign_DateByCaptureSup, AssignedCaptureOp_Name, 
LastCapture_Date, LastCaptureOp_Name, LastCapture_Date, 

и в обзоре мы точно такие же столбцы, но только Ingest заменяет обзор и почти то же самое происходит и для других столбцов таблицы (с одной или два столбца более или менее) и с целью повышения производительности по избранным запросам. Поэтому я решил не назначать одну таблицу для каждой стадии (традиционную нормализацию), и, наоборот, я завернул их все в одну унифицированную таблицу.

И теперь моя таблица имеет 30 столбцов, а число 30 в столбцах пугает меня, потому что я никогда не проектировал такую ​​большую таблицу. Какой из следующих сценариев наиболее подходит для моего случая, учитывая, что моя база данных должна поддерживать огромное количество данных (около 1500 записей добавляются ежедневно), а скорость жизненно важна?

1. после традиционной нормализации подход и сломать мой большой стол на 6 или 7 таблиц, каждая из которых имеет около 5 или 6 колонок о том, что я должен написать (п-1) присоединяется, чтобы получить полные данные цикла

2. держать мой текущий дизайн (одна таблицы с 30 столбцами) и найти решение для уменьшения размера бревен, так как в этом случае бревне будет более массивным (из-за обновления)

Я бы оценил ваш милосердные ответы.

Answer 1

Это слишком длинный комментарий.

30 полей не широкий стол. SQL Server поддерживает более 1000 полей на таблицу.

1,500 записей в день - это не большой объем вставок. Это всего около 500 тысяч рядов в год. SQL Server может обрабатывать миллиарды строк.

Если у вас возникли проблемы с бревнами, то у вас есть несколько вариантов, таких как:

• переключение в режим простого восстановления;
• периодически резервирует базу данных и обрезает журнал; и,
• используя контрольно-пропускные пункты базы данных.

Вы должны разбить таблицу на другие таблицы, если это имеет смысл с точки зрения реляционной модели - это, вероятно, потому, что 30 столбцов в таблице часто бывают комбинациями других объектов.Но ваша структура данных легко находится в сфере поддержки баз данных. И он может расти намного, намного больше без проблем (при условии, что ни один из ваших столбцов не является действительно большим).