Вопросы по моделированию БД

Question

Как бы вы смоделировали эти отношения в БД?

У вас есть объект Page, который может содержать PageElements.

PageElement может быть, например, Статьей или Картинкой. У таблицы Article, очевидно, есть другие элементы / столбцы, кроме Picture. Статья может иметь то есть. Столбцы «Заголовок», «Ведущий», «Тело» имеют тип nvarchar, в то время как изображение может иметь что-то вроде «AltText», «Путь», «Ширина», «Высота». Мне бы хотелось, чтобы это было расширяемым, кто знает, какие PageElements мне могут понадобиться через 3 месяца? Поэтому я думаю, что мне нужна таблица PageElementTypes.

Для отношений, как насчет таблиц, подобных этим:

Страницы с идентификатором и прочим мамбо-юмбо. (Дата создания, Видимо, что нет)

Pages_PageElements с PageId и PageElementId.

PageElements с идентификатором и PageElementTypeId и другим mumbojumbo (SortOrder, Visibility и т. Д.).

PageElementTypes с идентификатором и именем (например, «Article», «Picture», «AddressBlock»)

Теперь я должен создать столбец PageElementId в каждой таблице «Статьи», «Изображения», «AddressBlocks», чтобы все закончить? Вот где я немного застрял, это простые отношения 1: 1, так что это должно сработать, но как-то я могу что-то упустить.

Продолжение:

Рекомендованные ниже решения с отдельными атрибутами заставили бы меня хранить все атрибуты одного типа или нет? Что если один PageElement имеет атрибуты nvarchar (255), а некоторые - nvarchar (1000), что если некоторые являются целыми числами?

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

Answer 1

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

У меня был в целом хороший опыт работы с STI , и при условии, что вы не ожидаете множество классов и атрибутов, это самое простое решение. Простое очень хорошо в моей книге.

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

Answer 2

Так же, как вы настроили элементы страницы, вам нужно настроить атрибуты , связанные с элементами страницы.

Итак, у нас есть два элемента, которые являются расширяемыми элементами страницы и их атрибутами.

Предлагаю следующие таблицы:

Страница : Идентификатор страницы | ...

Элементы страницы : Идентификатор элемента страницы | ID типа элемента | Идентификатор страницы | ...

Тип элемента страницы : Идентификатор типа элемента | Метка типа элемента страницы

Тип атрибута элемента страницы : Идентификатор типа атрибута | ID типа элемента | Метка атрибута

Атрибуты элемента страницы : ID элемента страницы | Тип атрибута ID | Значение атрибута

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

Atttibute Тип ID 1 | Статья | "Название"

Atttibute Тип ID 2 | Статья | "Свинец"

Atttibute Тип ID 3 | Изображение | "AltText"

В таблице Атрибуты элемента страницы будет храниться фактическое значение атрибутов, связанных с элементом страницы. Пример:

Идентификатор элемента страницы 1 | Тип атрибута ID 1 | «Все любят Рэймонда»

ID элемента страницы 2 | Тип атрибута ID 3 | "Карта мира"

Answer 3

Полагаю, я просто пойду с тем, что получил, EAV для меня не вариант То, что я получил сейчас, - это несколько гибридный подход.

Answer 4

Я использую другое соглашение об именах, чем вы, но по сути это то, что я бы сделал:

PageElementType (PageElementTypeID, PageElementTypeName)

PageElement (PageElementID, PageElementTypeID)

Статья (ArticleID, PageElementID, ...)

Изображение (PictureID, PageElementID, ...)

Страница (PageID, ...)

PageHasPageElement (PageHasPageElementID, PageID, PageElementID) => {PageID, PageElementID} уникальны

Это то, что я делаю и, кажется, довольно хорошо нормализовано и хорошо работает.

Answer 5

Универсальным решением будет:

PageElementType: ID, Name, [Mumbo Jumbo]
PageElementTypeParameter: ID, PageElementTypeID, [Mumbo Jumbo]
Page: ID, [Mumbo Jumbo]
PageElement: ID, PageElementTypeID, [Mumbo Jumbo]
PageElementParameters: ID, PageElementID, PageElementTypeParameterID, Value, [Mumbo Jumbo]

Другими словами: есть таблица типов элементов страницы и связанная таблица, в которой перечислены возможные параметры для каждого элемента страницы (например, SRC и ALT для изображения; TEXT для статьи и т. Д.).

Тогда есть таблица со всеми страницами; связанная таблица, в которой перечислены элементы на каждой странице; и таблица, в которой перечислены значения параметров для каждого элемента.