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

Тема в разделе "Базы данных", создана пользователем Denixxx, 25 фев 2015.

Статус темы:
Закрыта.
Модераторы: latteo
  1. Denixxx

    Denixxx

    Регистр.:
    7 фев 2014
    Сообщения:
    247
    Симпатии:
    191
    Здравствуйте.

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

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

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

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

    Nei Nosce te ipsum

    Регистр.:
    5 сен 2009
    Сообщения:
    600
    Симпатии:
    468
    1й вариант
    ...на роль гуру SQL не претендую, но опыт работы с ним имеется достаточный)
     
    Denixxx нравится это.
  3. Denixxx

    Denixxx

    Регистр.:
    7 фев 2014
    Сообщения:
    247
    Симпатии:
    191
    А поподробнее можно — если не секрет, конечно. Почему именно первый вариант?
    Я больше склонялся к второму варианту, хотя конечно 1-й проще.
    Но он плохо расширяем в смысле «а вот если добавить ещё одного дилера».
    Второй вариант — самый большой минус — это конечно лишний запрос на каждый товар.
     
  4. Nei

    Nei Nosce te ipsum

    Регистр.:
    5 сен 2009
    Сообщения:
    600
    Симпатии:
    468
    Да, второй вариант действительно добавит лишний запрос, что "не есть хорошо".
    Если количество дилеров должно меняться, то может и 3й вариант, хотя можно и второй, если база небольшая и некритична нагрузка на неё.

    Итого по вариантам:
    1й проще и лучше но при условии фиксированного количества дилеров
    2й увеличивает количество запросов к базе
    3й в общем-то увеличивает нагрузку на обработку сериализации, плюс ИМХО излишне усложняет общую структуру
     
    Последнее редактирование: 26 фев 2015
    Denixxx нравится это.
  5. Denixxx

    Denixxx

    Регистр.:
    7 фев 2014
    Сообщения:
    247
    Симпатии:
    191
    Количество товаров сейчас 356, в перспективе может вырасти — ну пусть до 500.
    В таком разе, действительно, Ваши аргументы имеют резон и первый вариант проще и предпочтительней.
    Есть ещё одна причина, почему этот вариант лучше: ещё будет проще и импорт-экспорт цен в 1С делать.
    И править через Excel тоже проще.
    Спасибо за помощь.
     
  6. latteo

    latteo Эффективное использование PHP, MySQL

    Moderator
    Регистр.:
    28 фев 2008
    Сообщения:
    1.402
    Симпатии:
    1.182
    Голосую за первый вариант! И выборки легче делать и структура бд более понятная. Вариант актуален, если дилеров фиксированное количество. Но в принципе alter table позволит добавлять новых дилеров и на лайве...

    2) делаешь join, GROUP_CONCAT и все данные в одном запросе

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

    konov Писатель

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

    p.s. нужна будет помощь пиши
     
    Denixxx нравится это.
  8. xenator

    xenator Создатель

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

    Правда 500 товаров это так мало, что сложно отстрелить себе ногу извращенным образом.
     
    Denixxx нравится это.
  9. konov

    konov Писатель

    Регистр.:
    2 мар 2015
    Сообщения:
    8
    Симпатии:
    3
    т.е. вы предлагаете в одном поле, через какой - то разделитель добавить все цены?
    это не просто усложнит работу с данными, это ее еще и затормозит. А историю изменений, можно фиксировать в реестре цен или в каком то журнале покупок-продаж.
    Лучшую цену тоже легче некуда из такого реестра вытащить.
     
    Denixxx нравится это.
  10. Denixxx

    Denixxx

    Регистр.:
    7 фев 2014
    Сообщения:
    247
    Симпатии:
    191
    Я уже выбрал первый вариант, всем спасибо.
     
Статус темы:
Закрыта.