как разработать схему, в которой столбцы таблицы не фиксированы - PullRequest
Новая
       42

как разработать схему, в которой столбцы таблицы не фиксированы

1 голос
/ 29 мая 2010

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

  1. Обнуляемые столбцы в самой таблице Employee, т.е. без нормализации

  2. Вместо добавления столбцов, допускающих значение NULL, разделите эти столбцы в их отдельных таблицах, например: если Address является столбцом, который нужно добавить, то создайте таблицу Address [EmployeeId, AddressValue].

  3. Создание таблиц ExtensionColumnName [EmployeeId, ColumnName] и ExtensionColumnValue [EmployeeId, ColumnValue]. ExtensionColumnName будет иметь ColumnName в качестве «адреса», а ExtensionColumnValue будет иметь ColumnValue в качестве значения адреса.

    Таблица сотрудников
    EmployeeID
    Имя

    Таблица расширений столбцов
    ColumnNameId
    EmployeeID
    ColumnName

    ExtensionColumnValue table
    EmployeeID
    ColumnNameId
    ColumnValue

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

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

Ответы [ 6 ]

3 голосов
/ 29 мая 2010

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

Я бы порекомендовал вам посмотреть на couchdb, mongodb, lucene и т.д ...

Если схема часто изменяется в базе данных SQL, это приводит к кошмару, особенно с отчетами.

Помещение всего в триады (rowId, key, value) является гибким, но медленным из-за огромного количества записей.

Способ, которым вендоры ERP делают это, состоит в том, чтобы просто создать свою схему полей, в которых они уверены, и добавить большое число «flexfields» (то есть 20 чисел, 20 строк и т. Д.) В фиксированных именованных столбцах и использовать поиск таблица, чтобы увидеть, какой flexcolumn соответствует чему. Это обеспечивает некоторую гибкость в будущем при наличии статической схемы.

2 голосов
/ 29 мая 2010

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

Но для постоянно меняющихся значений, которые не могут быть объединены в подобные логические группировки, используйте две таблицы в дополнение к таблице EMPLOYEES:

  • EMPLOYEE_ATTRIBUTE_TYPE_CODES (два столбца, employee_attribute_type_code и ОПИСАНИЕ)
  • EMPLOYEE_ATTRIBUTES (три столбца: внешний ключ employee_id для EMPLOYEES, внешний ключ employee_attribute_type_code для EMPLOYEE_ATTRIBUTE_TYPE_CODES и VALUE)

В EMPLOYEE_ATTRIBUTES установите первичный ключ, из которого нужно сделать:

  • employee_id
  • employee_attribute_type_code

Это остановит дубликаты атрибутов для одного и того же сотрудника.

1 голос
/ 29 мая 2010

Если, как вы говорите, новые атрибуты будут добавляться часто, модель данных EAV может вам пригодиться.

1 голос
/ 29 мая 2010

Существует шаблон, называемый шаблоном наблюдения.

Для объяснения см. Эти вопросы / ответы: один , два , три .

В общем, выглядит так:

observation_model_02

Например, субъекты сотрудник, компания и животное могут иметь наблюдение Имя (черта), субъекты работник и животное могут иметь наблюдение Вес (измерение) и субъект бутылка пива могут иметь наблюдения Метка (признак) и Объем (измерение). Все вписывается в модель.

0 голосов
/ 29 мая 2010

Я бы использовал комбинацию 1 и 2. Если вы часто добавляете атрибуты, я не думаю, что вы справитесь с требованиями к данным.

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

Атрибуты, такие как менеджер, могут быть таблицей атрибутов или отношений. Если у вас есть несколько отношений между сотрудниками, рассмотрите таблицу отношений с типом публикации. Организациям с матричной структурой управления понадобится таблица соответствия.

Адреса и телефоны часто указываются в отдельных таблицах. Адресный ключ, такой как employee_id, address_type, будет подходящим. Если требуется история, добавьте столбец start_date к ключу.

Если вы храните историю, я рекомендую использовать столбцы start_date и end_date в соответствующих столбцах. Я пытаюсь использовать отношение, в котором запись активна, когда 'start_date <= date-Being -ised <end_date' имеет значение true. Атрибуты, такие как вес, цвет глаз и т. Д. </p>

0 голосов
/ 29 мая 2010

Объедините ваши таблицы ExtensionColumn в одну 

Property:
    EmployeeID foreign key
    PropertyName string
    PropertyValue string

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

...