Проектирование баз данных: отследите огромное количество атрибутов для каждого пользователя. Так так, что у меня, вероятно, закончатся столбцы (пространство памяти строки)

Я ценил бы некоторые мнения о беспокойстве, которое я имею.

У меня есть таблица [User] в моей базе данных с основным материалом, который Вы ожидали бы, как имя пользователя, пароль, и т.д...

Это приложение требует, чтобы я отследил огромное количество атрибутов для каждого пользователя. Так так, что у меня, вероятно, закончатся столбцы (пространство памяти строки).

Я испытываю желание добавить таблицу UserProperties с UserID, столбцами PropertyKey и PropertyValue. Этот подход соответствует хорошо требованиям.

Мое беспокойство - то, что, если каждый пользователь имеет, говорят, что 100 свойств, когда база данных имеет миллион пользователей в ней, у нас будет 100 000 000 строк свойства.

Я думал бы, что с кластерным индексом на UserID, что доступ будет все еще кричать быстро, и Вы действительно храните о том же объеме данных, как Вы были бы с подходом мегастолбцов.

Какие-либо идеи или мысли о проблемах производительности? Идеи для лучшего дизайна DB?

ОБНОВЛЕНИЕ:

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

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

Я использую LinqToSql, и в то время как я думаю таблицы с этим, много столбцов неэлегантны, я думаю, рассматривая все проблемы и компромиссы, это - вероятно, правильное, но я все еще стремлюсь услышать другие мнения.

8
задан Cœur 8 July 2019 в 05:02
поделиться

10 ответов

То, что Вы описываете, является базой данных Entity-Attribute-Value, которая часто используется для точно th ситуация, которую Вы описываете, редкие данные, связанные с единственным объектом.

Таблицу E-A-V легко искать. Проблема не находит строки, она находит связанные строки.

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

Мы можем легко искать ключи свойства, но ничто не группирует эти ключи свойства.

Википедия имеет очень хорошую статью об Электронном-V, но считайте ее теперь - это - главным образом работа одного автора и намечено для "улучшения".

11
ответ дан 3 November 2019 в 14:03
поделиться

Я сомневаюсь, что у Вас были бы так многие 1 к 1 значениями данных в таблице Users, что у Вас закончится пространство строки. Необходимо только разгрузить значения 1-many в другую таблицу, с помощью идентификатора пользователя в качестве Внешнего ключа. Я нахожу его вряд ли, что Ваша пользовательская таблица потребует такого количества полей VARCHAR(), в которые нельзя так или иначе превратиться FKs от основной таблицы значений. Какие пользовательские атрибуты Вы поддерживаете?

1
ответ дан 3 November 2019 в 14:03
поделиться

Какой-либо способ логически сгруппировать свойства? Вы, возможно, всегда не должны получать доступ к каждому свойству. Кроме того, если они будут логически сгруппированы, то будет легче понять, какие свойства доступны, где новое соответствие свойств, и т.д...

Группировки могут иметь один одному или связи "один ко многим" с пользователем...

1
ответ дан 3 November 2019 в 14:03
поделиться

Мы реализовали стратегию UserProperties в нескольких проектах. Это - общий шаблон, и с соответствующими индексами мы никогда не сталкивались с проблемой производительности.

Другое преимущество состоит в том, что у Вас может быть две или больше таблицы свойств в случае необходимости для управления пользовательским доступом. Например, общие свойства могли быть в таблице PublicUserProps, в то время как уязвимая информация (я не знаю то, что Вы храните, но ssn's, информация о платежной ведомости, и т.д.) мог быть в таблице ControlledUserProps, в которую только некоторые пользователи будут читать или права редактирования.

1
ответ дан 3 November 2019 в 14:03
поделиться

Подход таблицы UserProperties состоит в том, как я смоделировал бы его. Как Вы предположили, кластерный индекс на идентификаторе пользователя будет означать, что поиски диапазона на идентификаторе пользователя будут быстры (т.е. для всех свойств, касающихся отдельного пользователя). Мог бы также добавить некластерный индекс на UserID, и PropertyKey для единственного key-2-value выбирает на пользователя.

3
ответ дан 3 November 2019 в 14:03
поделиться

Я рекомендую считать подход известным как вертикальное разделение. Это означает, что Вы продолжаете определять таблицы с ключом UserID, Вы могли назвать их User1, User2, и т.д. Запустите новую таблицу при ударе максимального размера строки для базы данных. Преимущество этого подхода - то, что значения являются все еще истинными атрибутами базы данных. Это завершит экономящее время при работе с этими данными, например, привязкой данных.

Ключевой вопрос ответить: это, действительно приписывает? Они представляют struture информации, которую необходимо собрать о пользователе. Если так, лучший способ смоделировать их состоит в том, чтобы сделать их столбцами. Единственной причиной необходимо обратиться к вертикальному разделению, является предел размера строки базы данных.

Если с другой стороны, гибкая система атрибута требуется, то любой ценой идут со свойством система ценностей key/property. Например, если бы пользователям разрешили определить их собственные атрибуты динамично, то Вы определенно хотели бы ключ/систему ценностей. Однако я сказал бы, что ключ/значение не является лучшим способом, если Вы понимаете структуру своих данных и законно определили сотни атрибутов для пользователей.

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

7
ответ дан 3 November 2019 в 14:03
поделиться

Мне нравится подход таблицы метаданных, который описали Mitch Wheat и Вы. Но если у Вас есть несколько полей, которые будут использоваться более часто, чем другие (такие как имя, и т.д.) затем Вы могли бы найти, что, имея те, которые в таблице User, могли быть выгодными и затем соединить пользовательскую таблицу к UserProperties. Я предполагаю, что все это зависит от точных деталей Вашего дизайна.

1
ответ дан 3 November 2019 в 14:03
поделиться

Несколько опций я могу думать:

  • битовые поля: можно сохранить много значений там, и можно добавить больше полей по мере необходимости или даже использовать отдельную таблицу
  • поместите наиболее распространенные настройки в пользовательскую таблицу и настройки, которые каждый пользователь не мог бы иметь во второй таблице
  • только сохраните настройки, которые отличаются от значения по умолчанию
1
ответ дан 3 November 2019 в 14:03
поделиться

учитывая установленные ограничения, я не думаю, что у Вас действительно есть любой другой выбор!

хорошо, Вы могли разделить пользовательские атрибуты через несколько таблиц, совместно использующих тот же UserId как их первичный ключ (и кластерный индекс), но это может или не может улучшить производительность

если Вы только говорите приблизительно 100 атрибутов, это могло бы быть обработано одной таблицей (в MS-SQL, макс. 1 023 нестолбца ключа); если атрибуты являются только малонаселенными затем, пользовательская таблица атрибутов может потенциально быть более эффективной пространством (только Ваш профилировщик знает наверняка),

1
ответ дан 3 November 2019 в 14:03
поделиться

Я думал бы, что с кластерным индексом на UserID, что доступ будет все еще кричать быстро, и Вы действительно храните о том же объеме данных, как Вы были бы с подходом мегастолбцов.

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

Мой совет состоит в том, чтобы попытаться поместить все это в одну таблицу и затем разжечь его с некоторыми данными тестирования. ЕСЛИ это не работает затем, Вы могли бы спуститься, путь нескольких представляют в виде таблицы решение или даже решение недб (они не серебряные пули, в конце концов).

1
ответ дан 3 November 2019 в 14:03
поделиться
Другие вопросы по тегам:

Похожие вопросы: