Как бы вы реализовали очень широкий «стол»?

Question

Допустим, вы моделируете сущность, которая имеет много атрибутов (2400+), намного превышающих физический предел для данного механизма базы данных (например, ~ 1000 SQL Server). Ничего не зная об относительной важности этих точек данных (какие из них горячие / используются чаще всего), кроме ключей домена / кандидата, как бы вы это реализовали?

А) EAV. (Boo ... Родные реляционные инструменты выбрасывают в окно.)

B) Идите прямо через. Первая таблица имеет первичный ключ и 1000 столбцов, вплоть до предела. Следующая таблица - 1000 с внешним ключом к первой. Последняя таблица - это оставшиеся 400, также с внешним ключом.

C) Равномерно распределитесь по ceil( n / limit ) столам. Каждая таблица имеет четное количество столбцов, внешний ключ к первой таблице. 800, 800, 800.

D) Что-то еще ...

А почему?

Редактировать: Это скорее философский / общий вопрос, не привязанный к каким-либо конкретным ограничениям или двигателям.

Редактировать ^ 2: Как отмечали многие, данные, вероятно, не были нормализованы. Как правило, деловые ограничения в то время делали невозможным глубокое исследование.

Answer 1

Мое решение: исследовать дальше. В частности, установите, действительно ли таблица нормализована (при 2400 столбцах это маловероятно).

Если нет, реструктурируйте до тех пор, пока он не будет полностью нормализован (в этот момент в таблице может быть меньше 1000 столбцов).

Если он уже полностью нормализован, установить (насколько это возможно) приблизительные частоты населения для каждого атрибута. Поместите наиболее часто встречающиеся атрибуты в «домашнюю» таблицу для объекта, используйте 2 или 3 дополнительных таблицы для менее часто заполненных атрибутов. (Постарайтесь сделать частоту встречаемости критериями для определения того, какие поля должны идти в какие таблицы.)

Рассматривать EAV следует только для крайне малонаселенных атрибутов (желательно, не для всех).

Answer 2

Используйте Разреженные столбцы для до 30000 столбцов.Большое преимущество перед EAV или XML заключается в том, что вы можете использовать отфильтрованные индексы в сочетании с разреженными столбцами для очень эффективного поиска по общим атрибутам.

Answer 3

Не имея большого количества знаний в этой области, я думаю, что сущность с таким количеством атрибутов действительно нуждается в перепроектировании. Под этим я подразумеваю разбиение большой вещи на более мелкие части, которые логически связаны.

Answer 4

Ключевым элементом для меня является этот кусок:

Ничего не зная об относительной важности этих точек данных (какие из них горячие / используются чаще всего)

Если , у вас есть представление о том, какие поля являются более важными, я бы поместил эти более важные поля в «нативную» таблицу и позволил бы структуре EAV обрабатывать все остальное.

Дело в том, что без этой информации вы все равно действительно слепите.Независимо от того, есть ли у вас 2400 полей или только 24, у вас должно быть какое-то представление о значении (и, следовательно, относительной важности или, по крайней мере, логической группировки) ваших точек данных.

Answer 5

Я бы использовал таблицу атрибутов «один ко многим» с внешним ключом к сущности.

Например

сущности: id,

attrs: id, entity_id, attr_name, значение

ДОБАВЛЕНО

Или, как сказал бы Батлер Лэмпсон , "все проблемы в области компьютерных наук могут быть решены с помощью другого уровня косвенности"

Answer 6

Я бы хотел использовать вертикальный подход (увеличение количества строк) вместо горизонтального (увеличение количества столбцов).

Вы можете попробовать этот подход как

Таблица - идентификатор, имя свойства - значение свойства.

Преимущество подхода заключается в том, что нет необходимости изменять / создавать таблицу при введении нового свойства / столбца.

Answer 7

1. Я бы посмотрел на модель данных более внимательно.Это третья нормальная форма?Существуют ли группы атрибутов, которые должны быть логически сгруппированы в их собственные таблицы?

2. Предполагая, что оно нормализовано и у сущности действительно есть 2400+ атрибутов, я бы не стал так быстро EAV модель .ИМХО, это лучшее, самое гибкое решение для ситуации, которую вы описали.Он обеспечивает встроенную поддержку разреженных данных и хорошую скорость поиска, поскольку значения для любого данного атрибута можно найти в одном индексе.

Answer 8

Я бы вращал столбцы и делал их строками.Вместо того, чтобы иметь столбец, содержащий имя атрибута в виде строки (nvarchar), вы можете получить его в виде клавиши fkey обратно в таблицу поиска, которая содержит список всех возможных атрибутов.

Поворот таким образомозначает, что вы:

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