управление дополнительными полями

[grayz]

управление дополнительными полями

Суть вопроса как правильно (более эффективно) постоить работу с дополнительными полями.

есть "базовая таблица", например (в реальности больше полей) :
id | type | color | weight | created | modified

Но разные типы записей (выделяются по численному значению type) будут требовать дополнительные поля. Например, свойство (т.е. поле) "size" есть только у type=1 и т.п. Дополнительных полей будет около 10-15, типов до 5-7 (пока, может будет больше, но пропорция сохранится).

До сих пор у меня есть 2 варианта:

ВАРИАРНТ 1.
-создать таблицу "extra fields" в которые вносить название доп. полей, их принадлежность с определенному типу и может некторые другие их характеристики;
-создать таблицу "values of extra fields" в которой будет id записи из "базовой таблицы", id дополнительного поля и собственно значение.

ВАРИАРНТ 2.
-добавлять в "базовую таблицу" дополнительные поля для всех типов записей;
-создать таблицу "extra fields" в которую внести имена всех полей с "базовой таблицы" и тип к тоторому они относятся (общие поля будут с пустым значением) и с помощью ее отбирать нужные поля.

Господа профессионалы, скажите какой из этих вариантов более правильный/эффективный. Может есть другой путь?

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

 

[gogan]

Не гемороицца и все данные для записей хранить в одной таблице а не бить. Если я правильно понял задумку, то к этому надо добавить таблицу, которая "упорядочивает" разные типы данных: что-то типа id type pos, где id и type определяют строку в таблице с данными

 

[bubblegum]

Не геморроицца ) и сделать по варианту 1, как должно быть в "нормальной" в лучшем смысле этого слова базе. Таблиц получится всего 3.

 

[grayz]

спасибо за комменты.
никто 3го варианта не встречал?

 

[hermit_refined]

В связи с "эффективностью" вопрос: по этим extra fields выборка производиться будет? Если да, то в каких комбинациях?

 

[grayz]

Автор оригинала: hermit_refined
В связи с "эффективностью" вопрос: по этим extra fields выборка производиться будет? Если да, то в каких комбинациях?

ну с первым вариантом вроде все просто, запрос (сделан в Access для быстроты) будет такой:
SELECT tblExtaField.name, tblValue.value, tblBase.product
FROM (tblExtaField LEFT JOIN tblValue ON tblExtaField.id = tblValue.id_extafield) LEFT JOIN tblBase ON tblValue.id_record = tblBase.id
WHERE (((tblExtaField.type)=1) AND ((tblBase.type)=1));

неудобства - это большое кол-во записей в tblValue где хранятся значения допол.полей (если в базовой табл. tblBase будет 1000 записей то на 5 доп. полей будет 5000 записей в таблице tblValue) + надо поработать с обратоткой этих доп. полей ведь tblValue.value явно нужно делать varchar или mediutext, а какие значения может принимать нужно оганичивать программно.

со вторым вариантом думал сделать так: из "extra fields" отобрать имена полей принадлежащих к определенному типу и закинуть (наверно через массив) эти имена в SELECT для базовой таблицы. вроде проще + поля из базовой таблицы будут со своими свойствами.
Если минус: базовая таблица будет из 30-40 полей и это кол.-во будет со временем увеличиваться.

Блин, кручусь и так и этак и не могу найти нормальное решение. А эта структура она из основых в базе данных. Ошибусь и буде потом тяжко передалать.

хелп.....

 

[partizan]

Тебе ж сказали - делай по 1-му варианту, все будет ОК

 

[hermit_refined]

Ещё раз - будете ли вы выбирать данные из бд по значениям этих дополнительных полей? Да или нет?

 

[zerkms]

как должно быть в "нормальной" в лучшем смысле этого слова базе.

нормализация - не панацея.

фаулер в своей PoEAA предлагает 3 решения для реализации наследования в РБД:

Наследование с одной таблицей (Single Table Inheritance) (аналог варианта 1)
Наследование с таблицами для каждого класса (Class Table Inheritance)
Наследование с таблицами для каждого конкретного класса (Concrete Table Inheritance)

собственно варианты можно посмотреть в его книжке
"Архитектура корпоративных программных приложений" / "Patterns of Enterprise Application Architecture"

 

[grayz]

Автор оригинала: hermit_refined
Ещё раз - будете ли вы выбирать данные из бд по значениям этих дополнительных полей? Да или нет?

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

 

[hermit_refined]

grayz
Тогда зачем вносить логику этих дополнительных данных в бд?
Храните их все в одном text поле как сериализованный массив. С т. зр. эффективности и простоты - это оптимально.

 

[grayz]

Автор оригинала: zerkms
нормализация - не панацея.

фаулер в своей PoEAA предлагает 3 решения для реализации наследования в РБД:

Наследование с одной таблицей (Single Table Inheritance) (аналог варианта 1)
Наследование с таблицами для каждого класса (Class Table Inheritance)
Наследование с таблицами для каждого конкретного класса (Concrete Table Inheritance)

собственно варианты можно посмотреть в его книжке
"Архитектура корпоративных программных приложений" / "Patterns of Enterprise Application Architecture"

спасибо. нашел в инете описание + пару комментов. учу теорию

Автор оригинала: hermit_refined
grayz
Тогда зачем вносить логику этих дополнительных данных в бд?
Храните их все в одном text поле как сериализованный массив. С т. зр. эффективности и простоты - это оптимально.

поподробнее, пожалуйста.