SQL Server: одна таблица с 400 столбцами или 40 таблиц с 10 столбцами?

Question

Я использую SQL Server 2005 Express и Visual Studio 2008.

У меня есть база данных, в которой есть таблица с 400 столбцами. Все было (почти управляемо), пока мне не пришлось выполнять двунаправленную синхронизацию между несколькими базами данных.

Мне интересно, какие аргументы за и против использования базы данных 400 столбцов или базы данных 40 таблиц?

Таблица не нормализована и содержит в основном столбцы nvarchar (64) и некоторые столбцы TEXT. (нет типов данных, так как они были преобразованы из текстовых файлов).

Существует еще одна таблица, которая связана с этой таблицей и имеет отношение 1-1 (т. Е. Одна запись относится к одной записи в таблице из 400 столбцов).

Таблица представляет собой список файлов, которые содержат параметры, которые «подключены» к приложению.

С нетерпением жду ваших ответов.

Спасибо

Answer 1

На основании вашего описания процесса я бы начал с чего-то вроде этого. Модель упрощена, не фиксирует историю и т. Д., Но является хорошей отправной точкой. Примечание: параметр = свойство.

- Настройка представляет собой набор свойств . Одна настройка может иметь множество свойств , одно свойство принадлежит только одной настройке .
- Машина может иметь множество настроек , одна настройка относится только к одной машине .
- Свойство имеет определенный тип (температура, время работы, скорость вращения шпинделя), может быть много свойств определенного тип .
- Измерение и черта являются типами свойств . Измерение является числовым свойством , как скорость. Черта - это описательное свойство , такое как цвет или какой-либо текст.

Answer 2

Для широкого стола:

• Быстрый отчет о том, что он предположительно денормализован и поэтому соединения не нужны.
• Легко понять для конечных потребителей, поскольку им не нужно держать модель данных в голове.

Против широкого стола:

• Вероятно, необходимо иметь несколько составных индексов, чтобы получить хорошую производительность запросов
• Более сложно поддерживать согласованность данных, т. Е. Необходимо обновлять несколько строк при изменении данных, если эти данные находятся в нескольких строках
• Поскольку вам приходится обновлять несколько строк и поддерживать несколько индексов, одновременная производительность для обновлений может стать проблемой по мере увеличения блокировок.
• Вы можете получить записи с множеством пустых значений в столбцах, если атрибут не имеет отношения к объекту в этой строке, что может затруднить обработку результатов.
• Если ленивые разработчики делают SELECT * из таблицы, вы в конечном итоге перетаскиваете множество данных по сети, поэтому вам, как правило, приходится поддерживать подходящие представления подмножеств.

Так что все действительно зависит от того, что вы делаете. Если основной целью таблицы является создание отчетов OLAP, а обновления происходят нечасто и затрагивают несколько строк, то, возможно, правильной будет широкая денормализованная таблица. В среде OLTP это, вероятно, не так, и вы должны предпочесть более узкие таблицы. (Я обычно проектирую в 3NF, а затем по мере продвижения делаю денормализацию для производительности запросов.)

Вы всегда можете использовать подход нормализации и предоставления широкого обзора для читателей, если это то, что они хотят видеть.

Не зная больше о ситуации, на самом деле невозможно сказать больше о плюсах и минусах в ваших конкретных обстоятельствах.

Edit:

Учитывая то, что вы сказали в своих комментариях, рассматривали ли вы просто иметь длинную и тощую таблицу пар имя-значение, чтобы у вас были только столбцы UserId, PropertyName, PropertyValue? Возможно, вы захотите добавить в него и другие метаатрибуты; метка времени, версия или что-то еще. SQL Server достаточно эффективен в обработке таких таблиц, поэтому не стоит сбрасывать со счетов простое решение, подобное этому.