Как Вы реализовали бы очень широкую “таблицу”?
Скажем, Вы моделируете объект, который имеет много атрибутов (2400 +), намного больше, чем физический предел на данный механизм базы данных (например, ~1000 SQL Server). Знание ничего об относительной важности этих точек данных (которые чаще всего горячий/используют) помимо домена/ключей-кандидатов, как Вы реализовали бы его?
A) EAV. (шиканье... Собственные реляционные инструменты брошены из окна.)
B) Пойдите прямо через. Первая таблица имеет первичный ключ и 1 000 столбцов, прямо до предела. Следующая таблица 1000, внешняя адресуемый первому. Последняя таблица является оставлением 400, также внешний включенный.
C) Чередуйте равномерно через ceil( n / limit ) таблицы. Каждая таблица имеет четное число столбцов, внешнего манипулирования первой таблице. 800, 800, 800.
D) Что-то еще...
И почему?
Править: Это - больше философского/универсального вопроса, не связанного с любыми определенными пределами или механизмами.
Edit^2: Как многие указали, данные не были, вероятно, нормализованы. На обычные, бизнес-ограничения, в то время, когда сделано глубокое исследование невозможность.
8 ответов
Мое решение: исследуйте дальше. В частности, установите, действительно ли таблица нормализована (для 2400 столбцов это маловероятно).
Если нет, реструктурируйте его до тех пор, пока он не будет полностью нормализован (в этот момент, вероятно, будет меньше 1000 столбцов в таблице).
Если он уже полностью нормализован, установите (насколько это возможно) приблизительную частоту популяции для каждого атрибута. Поместите наиболее часто встречающиеся атрибуты в «домашнюю» таблицу для объекта, используйте 2 или 3 дополнительные таблицы для менее часто заполняемых атрибутов. (Постарайтесь сделать частоту встречаемости критерием для определения того, какие поля должны помещаться в какие таблицы.)
Рассматривайте EAV только для чрезвычайно редко заполненных атрибутов (желательно, не совсем).
Используйте Разреженные колонки для 30000 колонок. Большое преимущество перед EAV или XML заключается в том, что вы можете использовать Фильтрованные индексы в сочетании с разреженными колонками для очень эффективного поиска по общим атрибутам.
Не имея особых знаний в этой области, я думаю, что сущность с таким количеством атрибутов действительно нуждается в переработке. Под этим я подразумеваю разделение большого на более мелкие части, которые логически связаны.
Ключевым моментом для меня является этот отрывок:
Ничего не зная об относительной важности этих точек данных (какие из них наиболее популярны / используются чаще всего)
Если вы Имея представление о том, какие поля более важны, я бы поместил эти более важные поля в «родную» таблицу, а все остальное поручил структуре EAV.
Дело в том, что без этой информации вы все равно стреляете вслепую. Независимо от того, есть ли у вас 2400 полей или всего 24, вы должны иметь какое-то представление о значении (и, следовательно, относительной важности или, по крайней мере, логической группировке) ваших точек данных.
Я бы использовал таблицу атрибутов "один ко многим" с внешним ключом объекта.
Например,
сущностей: id,
attrs: id, entity_id, attr_name, value
ADDED
Или, как сказал бы Батлер Лэмпсон , «все проблемы в компьютерных науках могут решаться другим уровнем косвенного обращения "
Я бы повернул столбцы и сделал их строками. Вместо столбца, содержащего имя атрибута в виде строки (nvarchar), можно было бы использовать его как ключ к таблице поиска, содержащей список всех возможных атрибутов.
Вращение таким образом означает, что у вас:
- нет массы таблиц для записи деталей только одного элемента
- нет огромных широких таблиц
- вы можете хранить только ту информацию, которая вам нужна благодаря вращению (если вы не хотите хранить определенный атрибут, то просто не имейте этой строки)
Я бы много смотрел на модель данных внимательнее. Это 3-й нормальный форма? Есть ли группы атрибутов которые должны быть логически сгруппированы вместе в свои таблицы?
Предполагая, что это нормализовано и сущность действительно имеет 2400+ атрибутов, я не стал бы так быстро освистывать Модель EAV . ИМХО, это лучшее, самое гибкое решение для ситуация, которую вы описали. Он обеспечивает встроенную поддержку разреженных данных и обеспечивает хорошую скорость поиска, поскольку значения для любого заданного атрибута можно найти в одном индексе.
Я хотел бы использовать вертикальный подход (увеличение количества строк) вместо горизонтального (увеличение количества столбцов).
Вы можете попробовать такой подход, как
Таблица -- id , имя_свойства -- значение_свойства.
Преимущество этого подхода в том, что не нужно изменять / создавать таблицу при введении нового свойства / столбца.