Дизайн базы данных для поддержки динамических объектов

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

У меня есть некоторые сущности, которые имеют почти одинаковые атрибуты, разница составляет, возможно, 2-3 столбца.

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

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

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

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

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

P.S. Возможно, я не понимаю, но я добавлю больше описания, если это необходимо.

источник

2013-10-08 veljasije

Вы используете Entity Framework или какой-либо другой ORM? –

Сущность - это срок для записи в таблице, в этой ситуации – veljasije

Вам следует изучить «подкласс» и ORM. Это поможет вам понять, какие варианты есть, даже если вы «сворачиваете свои собственные». Вот стартовая статья: http://www.codeproject.com/Articles/232034/Inheritance-mapping-strategies-in-Fluent-Nhibernat – granadaCoder

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

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

источник

2013-10-08 20:24:05

ОК, это один из подходов, но когда появился новый объект, я должен изменить базу данных дизайн, а также код для отображения этих новых таблиц. – veljasije

Это правда. Я добавил еще одно решение, которое я когда-то видел, более динамичным, но сложнее реализовать. –

Одним из решений является хранение общих частей в одной таблице и конкретных частей в таблицах, относящихся к этому объекту.

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

Person Таблица

PersonID 
PersonName

Table Manager

ManagerID 
PersonID 
DepartmentManaged

Как только вы идете вниз путь наличия одной таблицы с переменными значениями поля - эффективный дизайн значения атрибута Entity - вы оказываетесь в вопросе о аду.

источник

2013-10-08 20:45:19 podiluska

Возможно, не самый лучший или самый академичный, но как насчет такой «открытой структуры»?

MainTable: все общие поля

SpecialProperties: дополнительные свойства, как это требуется
- MainRecordId (P, F-> MainTable)
- PropertyName (P)
- PropertyText
- PropertyValue (для числовых значений)

источник

2013-10-08 20:53:15

Дизайн базы данных для поддержки динамических объектов

ответ

Смежные вопросы