Архитектура БД для сущности с неизвестным кол-вом свойств

satsura

Новичок
Архитектура БД для сущности с неизвестным кол-вом свойств

Здравствуйте.
Помогите решить одну задачку по проектированию БД. Суть задачи состоит в следующем:
Например, у нас есть «Перевозчик», который осуществляет перевоз некоторого груза, на некотором транспорте.
Данный транспорт имеет свойства. О этих свойствах мы знаем только что у них есть наименование и значение, но мы не знаем их кол-во и вложенность.
Вот как выглядит этот пример наглядно:
Код:
Перевозчик
- Имя: Василий
- Транспорт: Автомобиль
  -- Цвет: Розовый
  -- Топливо: Бензин
или может быть так
Код:
Перевозчик
- Имя: Василий
- Транспорт: Собачья упряжка
  -- Собака №1
     --- Кличка: Тузик
     --- Окрас: Белая
  -- Собака №2
     --- Кличка: Шарик
     --- Окрас: Рыжая
     --- Глаза: Карие
Подскажите как лучше релизовать архитектуру данной БД?
 

LeFF®

Новичок
ИМХО подобную структуру гораздо удобнее хранить в XML
 

Димон

Новичок
Я бы сделал следующим образом:
Исходя из описанной ситуации мы имеем данные: Имя перевозчика, Тип транспорта, Характеристики
транспорта. Причем характеристики имееют разное кол-во значений, т.е. для всех машин мы заносим в таблицу цвет, тип топлива и для некоторых, допустим, наличие GPS-навигитора. Для собак мы заносим имя, породу и для некоторых указываем возраст собаки. Также подразумеваем, что у перевозчика может быть либо автомобиль (один или несколько), либо собака (одна или несколько).

Отталкиваясь от основных принципов пректирования БД:
1) не хранить значения типа NULL
2) хранить атомарные значения (т.е. те, которые после получения не надо обрабатывать)

Итак, создаем 5 таблиц:
1) Содержит список перевозчиков (table1):

ID | name | transportType
---------------------------------
ID - идентификатор перевозчика
name - имя перевозчика
transportType - тип транспорта

2) Содержит обязательные параметры автомобилей (table2):

ID | subID | color | fuelType
-----------------------------------
ID - идентификатор перевозчика - владельца авто
subID - идентификатор авто
color - цвет автомобиля
fuelType - тип топлива

3) Содержит обязательные характеристики собак (table3):

ID | subID | name | race
------------------------------
ID - идентификатор перевозчика - владельца собаки
subID - идентификатор собаки
name - имя собаки
race - порода

4) Содержит ID перевозчиков и subID автомобилей с установленным GPS-навигатором (table4):

ID | subID
-------------
ID - идентификатор перевозчика - владельца авто
subID - идентификатор авто

5) Содержит ID перевозчиков и subID собак, у котрых мы указаваем возраст(table5):

ID | subID | age
---------------------
ID - идентификатор перевозчика - владельца собаки
subID - идентификатор собаки
age - возраст собаки

Что получаем: в таблицы 1, 2, 3 пишем данные как обычно - здесь должно быть все очевидно. В таблицу 4 мы заносим данные, т.е. ID и subID только в том случае, если на автомобиле есть GPS-навигатор. В дальнейшем при извлечении данных мы применяем левостороннее объединение таблиц 1, 2, 4, связывая их по значениям ID и subID.

Пример левостороннего объединения:
SELECT table1.ID, name, transportType, color, fuel, table4.ID FROM table1 LEFT JOIN table2 ON table1.ID = table2.ID LEFT JOIN table4 ON table2.ID = table4.ID AND table2.subID = table4.subID;

Получим такую таблицу на выходе (предположим, что значения заполнены):

ID | name | transportType | color | fuel | ID
------------------------------------------------------
1 | Ivanov | auto | red | 92 | NULL
2 | Petrov | dog | NULL | NULL | NULL
3 | Smirnov | auto | black | 95 | 3

Смотрим на крайний правый столбец и видим, что у Смирнова, на машине установлен GPS. Здесь не важно значение, главное, что оно либо NULL, либо целое число.

С собачками подход аналогичный.

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

Ну вот типа, так. Если, что не ясно - поясню.
 

Akick

Новичок
Автор оригинала: Димон
Я бы сделал следующим образом:
Исходя из описанной ситуации мы имеем данные: Имя перевозчика, Тип транспорта, Характеристики
транспорта. Причем характеристики имееют разное кол-во значений, т.е. для всех машин мы заносим в таблицу цвет, тип топлива и для некоторых, допустим, наличие GPS-навигитора. Для собак мы заносим имя, породу и для некоторых указываем возраст собаки. Также подразумеваем, что у перевозчика может быть либо автомобиль (один или несколько), либо собака (одна или несколько).
Вы не разобрались в постановке задачи.

Данный транспорт имеет свойства. О этих свойствах мы знаем только что у них есть наименование и значение, но мы не знаем их кол-во и вложенность.
Вы предлагаете фиксированную структуру данных. А хранить нужно неизвестно что и неизвестно сколько.
 

StUV

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

Akick

Новичок
Автор оригинала: StUV
Akick
достаточно просто дерева
без всяких извращений
ибо

полностью описывает требования аффтора
Я в курсе ;о)
Пост мой был не автору, а изобретателю велосипеда )))
 

Akick

Новичок
Автор оригинала: StUV
так и открыл бы человеку глаза ;)
ИМХО, решение задачи очевидно. Вариантов не так много. Поиск в руки ;о)
Автор, судя по всему, задачу уже давно решил.
А отписался я, дабы менее искушённые разработчики не последовали столь прекрасному примеру.

PS. Сорри за офтоп.
 

Димон

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

StUV

Rotaredom
Димон
тебе известно только одно представление данных в виде дерева ?..
гугл сделает твой кругозор шире =)
 

Димон

Новичок
Гы :) Кругозором не обделен, но вот полезную инфу всегда рад почитать. StUV, может кинешь какую-нить ссылочку...
 

Aleks_P

Новичок
satsura
я думаю тебе может помочь поле 'неопределенных_данных' типа `rawdata` blob NOT NULL default ''. И хранить в нем сериализованные ассоц. массивы или объекты с произвольной структурой.
 
Сверху