Как типизировать сущность? Вопрос по проектированию.

mus

Новичок
Как типизировать сущность? Вопрос по проектированию.

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

Следующий блок информации перегружен сложными терминами. Краткое описание приведено после блока описания сущностей.


Материал - это сущность, имеющая несколько различных типов:

* Текстовая информация (стих, статья). Здесь мы встречаем первое ограничение - и стих и статья и рецензия и т.д. должны иметь одинаковые атрибуты, как то - название, дата, текст, ссылка. Для всей текстовой информации сущности материал это одинаково.
* Изображение.
* Мультимедиа (музыка, видео).

Суть типизации материала состоит в том, что отображение этого самого материала на сайте имеет свои особенности. Нельзя разместить и стихи и фотогалерею в одной категории, ибо получится полная каша. К стихотворению добавить картинку-рисунок, без которого не обойтись - это одно (картинка будет атрибутом сущности "материал" типа "текстовая информация").
На сайте будет возможность добавлять сущности этого типа разными способами, то есть для стиха - одна форма, для фотографий другая, для музыки и видео - третья.


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


Простая интерпретация.

Мы имеем категории, выводимые на сайте слева (как меню). Кликая по категории у нас отображается материал, который соответствует этой категории по принципу многие к одному. Материал может быть стихом, изображением или же мультимедиа-объектом (музыка, видео).

Отсюда вопрос - как объединить в реляционной базе данных объекты с разным количеством атрибутов? Нельзя же хранить в одной таблице стихотворение с массой собственных атрибутов и в этой же таблице информацию о mp3 файле.

1) Стоит ли разъединить эти сущности и разместить их в отдельных таблицах?
2) Если не стоит разъединять, то как правильно организовать подобную структуру?
 

Wicked

Новичок
2) Если не стоит разъединять, то как правильно организовать подобную структуру?
Сделать 2 таблицы: одну таблицу с общими характеристиками: название, дата создания, ...
Специфичные свойства хранить во второй таблице в столбик.

Обсуждалось на форуме не раз.
 

dark-demon

d(^-^)b
не, самый шик - хранить в одной таблице в виде гигантского дерева :)

но лучше всё-таки для каждой сущности - своя таблица.
 

Zetruger

ivan.chistyakov.name
все зависит от атрибутов и какие виды ты на них имеешь, если атрибуты - это важный элемент в твоей структуре данных, по которым может осуществляться поиск и отбор, то конечно нужно разносить

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

mus

Новичок
Zetruger

Да, атрибут штука важная в моей структуре. Что есть "разносить" в данном случае?

У меня есть следующие варианты решения этой проблемы:

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

Минусы варианта А:

1) Идеологически неправильное нагромождение структуры.
2) Нечеткая грань между разными типами одной сущности.

б) Сделать две таблицы:

param

param_id | key

1 "Название"
2 "Автор"
3 "Текст"
4 "Ссылка на объект"

material_value

material_id | param_id | value
1 1 "Мцыри"
1 2 "Лермонтов"
1 3 "БлаБлаБла..."
2 1 "Журавли"
2 2 "Гамзатов"
2 4 "zhur.mp3"

Минусы варианта Б (исправьте, пожалуйста, если я не прав):

1) Дополнительная нагрузка на сервер при выборке.
2) Усложнение выборки информации и кода приложения.
3) Отсутствие возможности типизации данных.
4) Невозможность использования агрегатных функций.

в) Разделение разного типа сущностей по разным таблицам. В таблице материалов будем указывать тип материала, а доп. информацию будем извлекать из других таблиц (text, music, photo)

Минусы варианта В:

1) Идеологически "грязный" вариант.
2) Нагромождение исх. кода лишними алгоритмами выборки информации.


Вот и выбираю из всех зол меньшее...

Может кто предложить структуру более оптимальную или указать на самый предпочтительный вариант из вышеперечисленных?
 
Сверху