Необязательная структура sql - PullRequest
Новая
       17

Необязательная структура sql

2 голосов
/ 06 декабря 2010

Мир БД не мой, поэтому, возможно, вопрос тривиален

Представьте себе проектирование БД, в которой хранятся данные из различных типов элементов (например, типов данных)

Понятия не имею, как мне это сделать, но вот как я это делаю 

id | quantity | price ... Kind | ID_k_foreing |

тогда для каждого вида предметов будет таблица со свойствами каждого типа

Таким образом, с помощью программного обеспечения я могу сравнить вид, а затем сделать объединения в соответствующую таблицу

как этот псевдокод 

switch(kind)
{
case chess_game:
      the join is made with a table like this:
      id_k| material | length | weigth ..
case car_toy:
      the join is made with a table like this:
      id_k| color | velocity | remote_control ...
case doll:
      the join is made with a table like this:
      id_k| name | height | clothes ..

...

}

Существует некоторый стандартный способ решения этой проблемы «типа данных» в структуре. без добавления хитрых программных функций?

спасибо

1 Ответ

4 голосов
/ 06 декабря 2010

Возможно, вы захотите взглянуть на этот вопрос .

Ответ Билла Карвина разбивает его таким образом.

У вас есть по крайней мере пять вариантов моделирования описанной вами иерархии типов:

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

Наследование таблицы классов : одна таблица для Products, в которой хранятся атрибуты, общие для всех типов продуктов.Затем по одной таблице для каждого типа продукта с сохранением атрибутов, специфичных для данного типа продукта.

Наследование бетонной таблицы : нет таблицы для общих атрибутов Products.Вместо этого одна таблица для каждого типа продукта, в которой хранятся как общие атрибуты продукта, так и атрибуты, специфичные для продукта.

Сериализированный LOB : одна таблица для продуктов, в которой хранятся атрибуты, общие для всех типов продуктов.В одном дополнительном столбце хранится большой двоичный объект полуструктурированных данных в формате XML, YAML, JSON или в другом формате.Этот BLOB-объект позволяет хранить атрибуты, специфичные для каждого типа продукта.Вы можете использовать причудливые Шаблоны Дизайна, чтобы описать это, такие как Фасад и Мементо.Но независимо от того, у вас есть множество атрибутов, которые нельзя легко запросить в SQL;Вы должны извлечь весь большой двоичный объект обратно в приложение и отсортировать его там.

Entity-Attribute-Value : Вместо этого одна таблица для продуктов и одна таблица, которая вместо этого переносит атрибуты в строки.колонн.EAV не является допустимым проектом в отношении реляционной парадигмы, но многие люди все равно его используют.Это «Шаблон свойств», упомянутый в другом ответе.Посмотрите другие вопросы с тегом eav на StackOverflow, чтобы узнать о некоторых подводных камнях.

Вам нужно разобраться, какой из них вам подходит.

...