Привет.

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

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

Первоначально я придумал такую структуру

Таблица объектов
id
type (1- кинотеатр, 2- кафе и т.д.)
title


Таблица свойств
id
object_id (номер объекта, которому соответствует свойство)
property_type (Для кино: 1-ширина экрана, 2- чилос мест в зале и т.д. Соответственно для других типов объектов)
value

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

Кинотеатр Алмаз, 3 метра
Кинотеатр Алмаз, 234 места
Кинотеатр Алмаз, Звук Dolby Digital
Кинотеатр Алмаз, Станция метро "Динамо"


А хотелось бы это все получить, конечно, одной строкой. Можно ли это како-то сделать при такой структуре БД или такая структура не жизнеспособна? Какаю структура тогда эффективнее в данном случае? 

Заранее спасибо.

ну, полная универсализация была бы, если б ещё отдельно таблицу со списком имен параметров и типов параметров(перечисление, строка, дата) и список имен типов объектов. и список того, какой тип какие параметры может иметь. 
тогда выйдет очень универсальная таблица, которую будет просто поддерживать, но большое количество связей приведет к тому, о чем пишешь ты: универсальные запросы по универсальной структуре выдают "универсальные" результаты. которые надо дополнительно парсит. потому что человеку не надо нечто вроде XML. ему подавай неоднородную структуру.
так что если ты напишешь запрос, то это будет запрос под вполне определенный тип объекта(например,  который выведет все известные тебе типы параметров для кинотеатра в виде не отдельных записей, а отдельных полей одной записи, но к баням уже запрос будет неприменим и придется писать для бань отдельный запрос).
итого: либо тебе придется писать далеко неуниверсальные запросы под каждый тип объекта(впрочем, сам запрос может храниться в БД в таблице "объекты" - тогда диссонанса между универсальным и конкретным не будет) или же парсить средствами клиентского ЯП возвращаенный "универсализированный" результат.

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

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

Кинотеатр Алмаз, 3 метра, 234 места, Метро "Динамо"
Кинотеатр Сатурн, 10 метров, 1090 мест, Метро "Сокол"

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

Добавлено через 55 секунд
PS БД MySQL

очень просто.


если каждого объекта будет задан каждый атрибут/параметр, то при использовании inner join и наличии необходимых ключей сильно тормозить на небольшом количестве записей не должно.
если же произвольное количество параметров может отсутствовать, то полджины left join насмешат СУБД до смерти.

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

К решению о  разработке собственной EAV, приходил, наверняка, почти каждый программист БД. Наверно это возрастное. Я бы сказал подростковое. Когда скилла уже достаточно, для того чтобы оценить трудозатраты на реализацию ER модели, а работать крайне лениво, возникает великий соблазн упростить себе жизнь. К сожалению, скилла, чтобы оценить сколь тяжел, тернист и бесперспективен этот путь, на этом этапе, у программиста не достаточно. А советы старших товарищей, мол "игра не стоит свеч", человеком, одухотворенным идеей, воспринимаются как консерватизм ленивых снобов.

rcdimon, не пуха тебе ни пера. Через это надо пройти.

Это сообщение отредактировал(а) Zloxa - 20.10.2008, 09:19

Zloxa, ой спасибо за дельный совет

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