Дилерские цены в БД

Статус
В этой теме нельзя размещать новые ответы.

Denixxx

Мой дом здесь!
Регистрация
7 Фев 2014
Сообщения
244
Реакции
216
Здравствуйте.

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

Как бы сделать это правильно? Чтобы в обозримом будущем иметь меньше геморроя.
1. Добавить в таблицу товаров 4 поля — дилер 1 уровня, дилер 2 уровня, дилер 3 уровня и т.п.
2. Сделать отдельную таблицу для дилерских полей —
id, itemid (id товара), dilerid (тип дилера), price (цена)
3. Добавить в таблицу товаров 1 поле, и в нём содержать все цены. Можно применить для этого сериализацию или json

Дилеров предполагается опознавать — с помощью специальных свойств, заданных пользователю.

Очень жду ответов от гуру SQL, уже решавших проблему с мультиценами, буду благодарен за обоснованный ответ.
 
1й вариант
...на роль гуру SQL не претендую, но опыт работы с ним имеется достаточный)
 
1й вариант
...на роль гуру SQL не претендую, но опыт работы с ним имеется достаточный)
А поподробнее можно — если не секрет, конечно. Почему именно первый вариант?
Я больше склонялся к второму варианту, хотя конечно 1-й проще.
Но он плохо расширяем в смысле «а вот если добавить ещё одного дилера».
Второй вариант — самый большой минус — это конечно лишний запрос на каждый товар.
 
Да, второй вариант действительно добавит лишний запрос, что "не есть хорошо".
Если количество дилеров должно меняться, то может и 3й вариант, хотя можно и второй, если база небольшая и некритична нагрузка на неё.

Итого по вариантам:
1й проще и лучше но при условии фиксированного количества дилеров
2й увеличивает количество запросов к базе
3й в общем-то увеличивает нагрузку на обработку сериализации, плюс ИМХО излишне усложняет общую структуру
 
Последнее редактирование:
Да, второй вариант действительно добавит лишний запрос, что "не есть хорошо".
Если количество дилеров должно меняться, то может и 3й вариант, хотя можно и второй, если база небольшая и некритична нагрузка на неё.

Итого по варианта:
1й проще и лучше но при условии фиксированного количества дилеров
2й увеличивает количество запросов к базе
3й в общем-то увеличивает нагрузку на обработку сериализации, плюс ИМХО излишне усложняет общую структуру
Количество товаров сейчас 356, в перспективе может вырасти — ну пусть до 500.
В таком разе, действительно, Ваши аргументы имеют резон и первый вариант проще и предпочтительней.
Есть ещё одна причина, почему этот вариант лучше: ещё будет проще и импорт-экспорт цен в 1С делать.
И править через Excel тоже проще.
Спасибо за помощь.
 
Голосую за первый вариант! И выборки легче делать и структура бд более понятная. Вариант актуален, если дилеров фиксированное количество. Но в принципе alter table позволит добавлять новых дилеров и на лайве...

2) делаешь join, Для просмотра ссылки Войди или Зарегистрируйся и все данные в одном запросе

3) сериализация допустима в конфиг таблице и то для несильно критичных полей или для временных логов. В остальном, она создаст ограничения, с которыми потом придётся пострадать...
Представь, что потребовалось увеличить все прайсы на 0,5%.
1) простой update
2) простой update
3) полная выборка, обработка на php, апдейт для каждой строки
 
Здравствуйте.

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

Как бы сделать это правильно? Чтобы в обозримом будущем иметь меньше геморроя.
1. Добавить в таблицу товаров 4 поля — дилер 1 уровня, дилер 2 уровня, дилер 3 уровня и т.п.
2. Сделать отдельную таблицу для дилерских полей —
id, itemid (id товара), dilerid (тип дилера), price (цена)
3. Добавить в таблицу товаров 1 поле, и в нём содержать все цены. Можно применить для этого сериализацию или json

Дилеров предполагается опознавать — с помощью специальных свойств, заданных пользователю.

Очень жду ответов от гуру SQL, уже решавших проблему с мультиценами, буду благодарен за обоснованный ответ.

Привет, конечно же сделать отдельную таблицу для диллерских цен.
В первом случае, усложнишь таблицу и конструкция не будет гибкой при выполнении запросов.
Третий случай самый непродуктивный, содержать множество значений, разделенных каким-либо знаком в одном поле, значительно усложняет выборку, могут возникать ошибки. Скорее всего при выборках придется применять или вложенный запрос (что вообще не очень) или оператор "LIKE", который однозначно медленней работает нежели свертка по ключевым полям.
И так же плюс второго варианта, что ты при изменении диллерской цены, будешь работать, с целевой таблицей.

p.s. нужна будет помощь пиши
 
Я бы сделал третий вариант, во-первых усложнение запросов небольшое, во-вторых не обязательно все товары всегда будут совпадать, число будет меняться. В-третьих появляются новые возможности, например выбор лучшей цены. Если не удалять старые значения, то можно будет следить за изменением цен во времени. В-четвертых вы не ограничены количеством поставщиков, сегодня их 3 завтра 15.

Правда 500 товаров это так мало, что сложно отстрелить себе ногу извращенным образом.
 
Я бы сделал третий вариант, во-первых усложнение запросов небольшое, во-вторых не обязательно все товары всегда будут совпадать, число будет меняться. В-третьих появляются новые возможности, например выбор лучшей цены. Если не удалять старые значения, то можно будет следить за изменением цен во времени. В-четвертых вы не ограничены количеством поставщиков, сегодня их 3 завтра 15.

Правда 500 товаров это так мало, что сложно отстрелить себе ногу извращенным образом.
т.е. вы предлагаете в одном поле, через какой - то разделитель добавить все цены?
это не просто усложнит работу с данными, это ее еще и затормозит. А историю изменений, можно фиксировать в реестре цен или в каком то журнале покупок-продаж.
Лучшую цену тоже легче некуда из такого реестра вытащить.
 
Я уже выбрал первый вариант, всем спасибо.
 
Статус
В этой теме нельзя размещать новые ответы.
Назад
Сверху