Поля таблицы про запас

[ПРЕВЕД]

Поля таблицы про запас

Привет.
Имеется таблица сущностей, у которых может быть разное число свойств. Количество свойств умозрительно ограничивается 10-ю. Я подумал, что можно добавить к таблице 10 разнотипных полей (TEXT, VARCHAR, INT) про запас и использовать их по мере необходимости. Смущает то, что в этом случае у записи будет некоторое число пустых полей.

Какие недостатки присутствуют у такого решения?
Спасибо за ответы.

PS
Расположить свойства в отдельных таблицах можно, но я не знаю, как в таком случае оптимальнее делать выборку и сортировать сущности по произвольному свойству (у меня получается гораздо больше запросов к БД).

 

[chisto_tolyan]

недостатки - отсутсвтие нормализации.
делать отдельную таблицу для свойств.
Таблица сущностей:
id, entity
Таблица свойства:
id, entity_id, property
Запрос делать типа:
[SQL]
SELECT * FROM entity_tbl AS e
LEFT JOIN property_tbl AS p ON e.id=p.entity_id
WHERE entity="some" AND p.property="other"
[/SQL]

 

[ПРЕВЕД]

chisto_tolyan
Извините, если сламерю, но на этом форуме читал, что нормализация и оптимизация - часто задачи противоположные.

Запрос делать типа:

Т.е. в таком запросе будет по JOIN на каждое свойство и мне нужно заранее знать их количество и желательно имена?

 

[Барби]

ограничение - если появится 11-ое свойство будешь делать +1 поле?

с сущностями тоже не понятно... каждая запись - разнородная сущность или всё же есть группы сущностей с идеентичными наборами типов параметров? если так, то нужна ещё и третья таблица, с определением типов параметров для каждой группы сущностей

 

[chisto_tolyan]

Т.е. в таком запросе будет по JOIN на каждое свойство и мне нужно заранее знать их количество и желательно имена?

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

 

[ПРЕВЕД]

Барби

если появится 11-ое свойство

Про это я уже писал. Вероятность его необходимости меня устраивает, т.к. она сравнительно мала.

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

Группы сущностей есть (как и соответствующие таблицы). Их количество и набор свойств в каждой заранее неизвестны и меняются динамически.

chisto_tolyan

что именно тебе нужно сортировать и как

Виды сущностей и наборы их свойств задаются пользователем и могут впоследствии изменяться им же. Банальным примером будут "товары", которые нужно сортировать по свойству "цена" или "рейтинг".

Я пришел к трем вариантам:
1) Уже описанный - поля про запас.
Вариации выборки при один ко многим:
2) Выбрать сущности + JOIN'ы для свойств, по которым нужна сортировка, и получить id сущностей в отсортированном порядке. Затем выбрать все свойства по id сущностей.
3) Выбрать сущности + JOIN для каждого свойства (до 10 объединений в итоге) и сортировка по заданным свойствам.

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

 

[Барби]

очень не конкретно... ты говоришь про сущности, значит говоришь про общий случай. ты спрашиваешь как делаем мы в таком случае? я делаю тремя таблицами.
про товары и сортировку ты очень плохой пример привёл.
цена и рейтинг есть у всех товаров и сортировка по этим параметрам никаких проблем не выхывает ни в каком случае... поскольку эти поля в общем то в любом случае хранятся вместе с названием и уникальным номером товара, причём название и тип полей вполне известен! если говорите о сортировке не понятных параметров, например Диагональ для теливизоров и сопративление у наушников, то сортировка по спецефичиским параметром имеет смысл только внутри категории.
выводы:
1. одной таблицой делать вообще нельзя, если хочешь разные сущности да ещё и с сортировкой.
2. двумя таблица тоже не рекомендую, поскольку работа с такой структурой будет весьма затруднительна, да у тебя есть запись с сылкой что это свойство от такого то продукта, а инфа о том что это за свойство? из какой группы свойств (например, длина шнура это или сопративление).

 

[ПРЕВЕД]

Барби

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

В моем случае все поля/параметры/свойства неспецифические, кроме идентификатора. Я бы не хотел создавать по таблице для каждого вида сущности. Или это вполне нормально?

одной таблицой делать вообще нельзя, если хочешь разные сущности да ещё и с сортировкой

двумя таблица тоже не рекомендую

Я и не делаю только одной/двумя таблицами. Естественно, выше был упрощенный пример. Таблицы с мета-информацией о свойствах и сущностях - само собой разумеющееся.
Меня больше интересует выборка.

 

[Барби]

products (id,name,price) - наши сущности
params (id,pid,name) - описание параметров
values (id, prod_id, param_id, val) - значение параметров

запрос для сортировки:
select products.* from products left join values on products.id=values.prod_id where values.param_id=_айди параметра по которому хотим сортировать_ order by values.val


ну тока имена нужно поменять, а то мускул ругатся наверное будет )

 

[ПРЕВЕД]

Барби
Да да. Это мой вариант под номером 2.
Видимо, немного потыркаюсь, но так и буду делать. Спасибо!