Хранение документов разной структуры

[_RVK_]

Хранение документов разной структуры

В общем то, лучшим примером будут прайс-листы.

Задача:
Необходимо создать БД для хранения данных о товарах. Вложенность неограниченная. Помимо наименования, у товара может быть определенное число других характеристик например срок гарантии, цена, цена с доставкой и т.п. причем количество и перечень таких характеристик может быть различным у товаров относящихся к разным категориям. Пользователь может в любой момент добавить характеристику или удалить. Так же можно добавлять новые прайсы свободной структуры.

Решений вижу несколько:

1. Таблица имеет поле text в котором хранится xml с описанием доаолнительных полей. Что то типа:
<fields>
<field name="Name of field" value="value of field" type="text"/>
</fields>

Но здесь возникают проблеммы сортировки, поиска, выборки по полям...

2. Таблица с товарами связанна с другой в отношении один ко многим. Во второй таблице 2 поля: имя параметра, значение параметра.

Тут недостатком является фиксированный размер полей и ресурсоемкие операции объединения таблиц при выборке и поиске.

3. Каждому прайсу своя таблица+таблица с описанием.

Недостаток только в сложности реализации.

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

 

[Макс]

в поиск сам пойдешь или послать ?

 

[Кром]

>в поиск сам пойдешь или послать ?

В поиск сходить ему можно, вот только по какому слову?

 

[_RVK_]

Макс
Если пошлешь, не обижусь Хочешь сказать есть обсуждение этого вопроса, а я его пропустил?

 

[Vital_N]

Макс
действительно пошли и меня заодно - тоже интересна эта тема, если уже обсуждалась - ткни плиз

 

[Макс]

http://phpclub.ru/talk/showthread.php?old=1&threadid=35790
http://phpclub.ru/talk/showthread.php?s=&threadid=48569&
http://phpclub.ru/talk/showthread.php?s=&threadid=40767&
http://phpclub.ru/talk/showthread.php?s=&threadid=44776&

-~{}~ 28.01.05 13:27:

В поиск сходить ему можно, вот только по какому слову?

я все по слову "характеристик*" нашел

 

[_RVK_]

Макс
Спасибо, не догадался поискать по слову "характеристик".
Но из того что прочитал вывод один, использовать вариант №2
Я так действительно когда-то делал. Но с тех пор у меня появилась странная уверенность что лучший вариант все же 3, но он почему-то не рассматривется. Есть грабли о которых я не подумал?

 

[Макс]

лучший вариант все же 3, но он почему-то не рассматривется.

например поиск товара делать неудобно (если нужна такая фича)
При добавлении новой категории товара надо создавать новую таблицу - ИМХО создание таблиц должно просиходить один раз (при установке скрипта или при его апдейте)
Да и вообще мне он интуитивно кажется нелогичным.

 

[_RVK_]

Макс

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

Согласен. Но и здесь не намного сложнее. ведь есть таблица с оаписанием полей. А поиск "только в этом прайсе" Будет еще и быстрее.

Да и вообще мне он интуитивно кажется нелогичным

А мне кажется нет ничего логичнее хранить таблицу с n полями таблице БД и теми же n полями.

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

 

[Long]

_RVK_ несколько модифицированный вариант номер 2 - однозначно, ибо он позволяет сделать очень гибкую систему хранения разнородной информации. например, если у тебя имеется вложенный каталог, то можно разнести однотипные "блоки" характеристик на уровень выше.

 

[_RVK_]

Long

то можно разнести однотипные "блоки" характеристик на уровень выше

Поясни.

-~{}~ 28.01.05 16:09:

вот, набрасал структуру БД

3 таблицы что слева постоянные. 2 правые таблицы будут создаваться для каждого из прайсов. price_desc содержит описания полей для таблицы price. Сама price это таблица для конкретного типа прайсов. Она создается при добавлении нового прайса. При добавлении/удалении полей выполняется запрос ALTER TABLE price.... и изменяется таблица table_desc

 

[Long]

_RVK_ если у тебя есть допустим прайс на машины, примерно такой структуры:
Машины
машины крутой комплектации
машины средней крутости комплектации
машины с базовой комплектацией.

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

 

[_RVK_]

Long
Ага, хороший довод)) Принято.
Есть еще?

 

[antonio]

Почитай, в свое время я начал готовить ТЗ для буржуев, но меня не пустили в страну

http://anton.concord.ru/cms.doc

идея близка к №3 но рассматривается более общий подход

 

[Ramzes]

Автор оригинала: _RVK_
Есть еще?

есть еще такой http://www.stikriz.narod.ru/art/oobd.htm

 

[yugene]

Originally posted by antonio
Почитай, в свое время я начал готовить ТЗ для буржуев, но меня не пустили в страну

Прежде, чем готовить ТЗ для буржуев, хорошо б язык буржуйский подучить. Я не смог найти практически ни одной корректной фразы в этом документе

 

[Vasya]

Таблица товаров с общими для всех товаров полями. Как то: id, тип, название, производитель, базовая цена, количество...
Пример: 982, 12, 423, 'Маленькая задняя варежка для хомячка', 100, 92

Таблица, описывающая спец характеристики: id, название
Пример: 37958, 'Цена товара до полнолуния'
Пример: 2431, 'Цена товара после полнолуния'

Таблица, связывающая определенный тип товара с характеристиками (многие ко многим)
Тип товара и эту таблицу, вообще говоря, можно выкинуть. Но, с ними вроде как удобнее. Можно сразу выбрать товар по типу. Если известен тип товара, то сразу можно сказать какие характеристики у него есть, а каких нет. Ну, и т.д.
Пример:
12, 2431
12, 37958

Таблица, содержащая фактические значения для характеристик: id_товара, id_характеристики, содержание. primary_key(id_товара, id_характеристики)
982, 37958, 99
982, 2431, 105

 

[vitus]

Originally posted by Ramzes
есть еще такой http://www.stikriz.narod.ru/art/oobd.htm

<cut> Правда, у меня сервер InterBase 6.01 падал от таких запросов ...
</cut>
- вообще такая мечта в конце 90х посещала не одну неглупую голову с ленивыми руками ...

а что мешает взять сериализованный объект в xml например и индексировать его по варианту 2 ?
Фактически комбинация вариантов 1 и 2.
- это даст выигрыш при поиске по полям, и выигрыш при поднятии всего объекта, незначительный проигрыш будет при сохранении (создании, изменении).

индекс можно сделать не типизированным, - обойтись например varchar(255) для всех типов полей.
сам объект можно хранить в файле или в мемо поле (если регилия позволит )

вариант 3 хорошо подходит для редко изменяемых типов компонентов.

 

[_RVK_]

а что мешает взять сериализованный объект в xml например и индексировать его по варианту 2 ?
Фактически комбинация вариантов 1 и 2.
- это даст выигрыш при поиске по полям, и выигрыш при поднятии всего объекта, незначительный проигрыш будет при сохранении (создании, изменении).

Почему комбинация. Это и есть чистой воды первый вариант.

вариант 3 хорошо подходит для редко изменяемых типов компонентов

У одного из нас проблеммы с терминологией О каких типах каких компонентов идет речь?

 

[vitus]

Originally posted by _RVK_
Почему комбинация. Это и есть чистой воды первый вариант.

да, только без проблем сортировки, поиска и выборки по полям

...хотя бывают исключения, не критичные для поставленной задачи.

У одного из нас проблеммы с терминологией О каких типах каких компонентов идет речь?

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

... что-то компоненты стали до боли напоминать ентити бины, не к добру это ...