Как лучше хранить прайсы в БД

_RVK_

Новичок
Как лучше хранить прайсы в БД

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

Romantik

TeaM PHPClub
Когда-то я занимался подобным, много было исследований и врезультате работы выяснилось, что все ошибки из-за человеческого фактора, особенно когда путают валюты и гарантии (годы на месяцы). Выход был только один- шаблон прайса для клиентов.
 

Romantik

TeaM PHPClub
четкой шаблон с описанием полей и ключевые ячейки
Пример (сразу CSV):
1;2;3;4;5
----------------
1;Комплектующие;50;0;0;0
1;MB for AMD;100;1;0;0
1;MB MSI 6380;0;50.5;60.5;12
1;MB Soltek;1;60.0;70.0;12
2;MB for Intel;100;1;0;0
2;MB MSI i845;0;50.5;60.5;24
2;MB Soltek i845;1;60.0;70.0;24
2;периферия;50;0;0;0
......
столбцы:
3-й : если 50- раздел, если 100- подраздел, иначе товар(1 в наличии, 0- отсутствует)
4-й и 5-й если товар, то цены (тут свобода действий)
1-й - ИД соотв таблицы (У меня 3 таблицы Раздел,ПодРаздел, Товар)
6-й гарантия мес

В качестве шаблона яркий прайс с выделением по цветам РАЗДЕЛА,ШАБЛОНА,ТОВАРА
Один раз его заполнить грамотно. а потом клиент только правит и присылает, а обработчик уже дело другое.
И если клиент ввел неверные данные, попутал валюты или сроки гарантий- эго проблемы т.к. есть шаблон.

Удачи.
 

Popoff

popoff.donetsk.ua
я бы создал примерно такую таблицу:

kPrice int not null,
index id(id), #ключ не уникальный
kField int not null, #ссылка на другую таблицу, в которой описывается что это за поле (название, тип)
data tinyblob not null

одной строке прайса соответсвует много строк в таблице; одной ячейке прайса будет соответствовать одна строка в этой таблице; все данные хранишь в виде строк

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

kHead int not null, #идентификатор заголовка прайса
iField tinyint not null, #номер столбца в заголовке
unique index(kHead,iField),
sType tinyblob not null #тип данного - по нему определяешь в какой таблице искать это данное

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

_RVK_

Новичок
Но эти данные нужно в базу занести, тем более что клиент сам хочет обновлять сайт. Поэтому для каждого шаблона своя таблица... или я чего то не понял.
Мне просто интересно, есть ли способ хранить данные для всех прайсов в одной таблице, или правильнее все же для каждого разную. Можно конечно одно поле типа текст и в нем значения разделенные например точкой с запятой.... Вот я и спрашиваю, как правильнее...
 

Сергей123

Новичок
Для случая "4 поставщика и редкое добавление новых" я писал отдельный парсер для каждого поставщика, каждый из которых приводит соотв-щий прайс к одной единственной структуре таблиц. Потом - универсальный обработчик хранящихся прайсов.
Тебе, похоже, это не подойдёт.
 

Popoff

popoff.donetsk.ua
правильно :) количество таблиц не должно расти с возрастанием количества прайсов. если у прайса сложная структура, то для его (конкретного, а так же всех остальных прайсов) хранения может потребоваться более чем одна таблица. но это будет ограниченное число таблиц, которое не зависит от числа разных прайсов, которые в них хранятся.

а вообще, по-моему, и вариант Романтика и мой именно так и работают :) все прайсы - в одной, максимум нескольких таблицах :)
 

_RVK_

Новичок
2Popoff

Думал и об этом тоже, но это кажется не рациональным, например описание товара длиннее чем номер телефона, а тип поля char так придется ставить по максимуму размер поля. Отдельную таблицу для телефонов? а там еще поле какого нибуть типа товара где вообще значения из 2х букв....
Может я зря заморачиваюсь, но хочется выполнить не просто заказ, а так чтоб потом аналогичные заказы делать дня за 2.... те хочу что то универсальное сделать....
 

Popoff

popoff.donetsk.ua
Думал и об этом тоже, но это кажется не рациональным, например описание товара длиннее чем номер телефона, а тип поля char так придется ставить по максимуму размер поля.
А ты не ставь char :) Ставь tinyblob :)
Отдельную таблицу для телефонов? а там еще поле какого нибуть типа товара где вообще значения из 2х букв....
Можно создать отдельные таблицы для данных разного типа. А типов там не так уж и много :)
Может я зря заморачиваюсь, но хочется выполнить не просто заказ, а так чтоб потом аналогичные заказы делать дня за 2.... те хочу что то универсальное сделать....
Правильное желание :)
 

_RVK_

Новичок
Так, все советуют конечное количество таблиц? А чем же тогда плоха генерация новой таблицы? Ведь все будет визуализированно до нехочу, и прозрачно? А данные будут храниться в таблице точно той структуры что и прайс...
Да мы еще забыли такой аспект как скорость.... Например поиск... выборка... добавление данных... Например хранение CSV в одном поле сразу отпадает так как индекс по этому полю такой большой не построишь....
 

Popoff

popoff.donetsk.ua
а вообще - расставляешь индексы и все должно работать очень хорошо :)

если я правильно знаю, то файловая система не индексирует файлы в каталогах :) она занимается линейным поиском :) будет ли это быстрее при большом количестве прайсов?
 

Popoff

popoff.donetsk.ua
Например хранение CSV в одном поле сразу отпадает так как индекс по этому полю такой большой не построишь....
А ты не храни CSV в одном поле - храни в нескольких :D
Полях, но в одной таблице :)
 

Popoff

popoff.donetsk.ua
кстати гороря, в разделе 12.6 мануала по мусклу написано:
In some cases it's convenient to pack and store data into a blob. In this case you have to add some extra code in your appliction to pack/unpack things in the blob, but this may save a lot of accesses at some stage. This is practical when you have data that doesn't conform to a static table structure.
Похоже как раз на твой случай :)
Можно вообще тогда создать одну таблицу с максимумом столбцов в ней и хранить в каждом столбце что попало :)
 

_RVK_

Новичок
Ладно, наверное так и сделаю. Собственно плюсы и мнусы есть и у того и у другого подхода, но так проще реализовать.
 

weiss

Guest
Привет!
Когда-то тоже была такая проблема. Обошелся следующим методом. Может не совсем оригинально, но свои задачи выполняет.

Структура следующая:
t_price - таблица прайсов
---------
p_id int - уникальный идентификатор
price varchar - название прайса
description text -описание

t_cells
--------
p_id | int primary key - к какому прайсу пренадлежит
row_id | int primary key - номер строки
col_id | int primary key - номер ячейки
rowspan | int - сколько строк объединить
colspan | int| - сколько столбцов объединить
item | varchar - значение ячейки
header | tinyint - признак заголовка (у меня использовалось чтобы выделить строку как заголовок и выводить другим цветом)


Смысл в том, что в t_cells хранятся значения всех ячеек.
выборка проста select * from t_cells where p_id=? order by row_id, col_id.
И по полученным параметрам генерируем правильный HTML.

Громоздко только в создании структуры. Дальше тему не развивал, но у меня не было реализованы функции изменения структуры прайса (добавить/удалить строку-ячейку). Думаю, что можно доделать и это.

Была написана пошаговая администрилка.
1. Создаем структуру прайса.
2. Вбиваем/Редактируем значения ячеек. -

Если были бы какие-то изменения в структуре, то пришлось бы создавать заново прайс. Хорошо что прайсы маленькие, и не часто изменялись :).
 
Сверху