Хотелось бы выслушать идеи или готовые паттерны для следующего случая:
Имеется магазин и список товаров. У товара есть хар-ки (цена, название). Пользователь приобретает товар. Информация о заказе сохраняется в базу. При изменении стоимости товара в заказе должна оставаться прежняя цена. Так же при удалении товара заказ тоже должен оставаться.
Делать отдельную таблицу "заказ" несвязанную с таблицей "товар" и хранить там данные, актуальные на момент заказа?
Как это правильнее реализовать с точки зрения проектирования БД?
Здравствуйте, Аноним, Вы писали:
А>Добрый день,
А>Хотелось бы выслушать идеи или готовые паттерны для следующего случая:
А>Имеется магазин и список товаров. У товара есть хар-ки (цена, название). Пользователь приобретает товар. Информация о заказе сохраняется в базу. При изменении стоимости товара в заказе должна оставаться прежняя цена. Так же при удалении товара заказ тоже должен оставаться.
А>Делать отдельную таблицу "заказ" несвязанную с таблицей "товар" и хранить там данные, актуальные на момент заказа?
А>Как это правильнее реализовать с точки зрения проектирования БД?
А>Спасибо
Сформулируй что такое магазин. Вообще то список товаров с его характеристиками существует отдельно и независимо от его наличия. Т.е. склада. Именно на склад товар и поступает. Его характеристике в списке, А цена (закупки и/или продажная) это характеристика товара поступившего на склад. Остальные его характеристики в списке товара. Затем что за проблема с заказом? Там указывается продажная цена, и этот товар снимается со склада в каком-то смысле. И его цена не может поменяться на складе.Он уже продан и его на складе быть не должно. Может поменяться продажная цена товара на складе, или закупочная если это новые поступления этого товара на склад.
Ну, где-то так должно быть в терминах склада и заказа. Какую роль тут выполняет магазин это уже как поставлена задача.
Здравствуйте, Аноним, Вы писали:
А>Добрый день,
А>Хотелось бы выслушать идеи или готовые паттерны для следующего случая:
А>Имеется магазин и список товаров. У товара есть хар-ки (цена, название). Пользователь приобретает товар. Информация о заказе сохраняется в базу. При изменении стоимости товара в заказе должна оставаться прежняя цена. Так же при удалении товара заказ тоже должен оставаться.
Справочник товаров (Ид; Наименование; Описание)
Справочник цен товаров (Ид; Ид товара; Дата; Цена)
Документы поступления на склад — Приходные ордера (Ид; Номер; Дата; Поставщик; Склад)
Товары по приходным ордерам (Ид; Ид ордера; Ид товара; Кол-во; Цена поступления)
Здравствуйте, Аноним, Вы писали:
А>... При изменении стоимости товара в заказе должна оставаться прежняя цена.
В таблице с детализацией заказа храни цену на товар.
А>...Так же при удалении товара заказ тоже должен оставаться.
Добавь в товару атрибут "Удалён" и при удалении товара просто выставляй этот флаг, а дальше фильтруй.
Наука изощряет ум; ученье вострит память.
(c) Козьма Прутков
Здравствуйте, Аноним, Вы писали:
А>Как это правильнее реализовать с точки зрения проектирования БД?
Именно это так как написано правильнее всего реализуется версионностью информации о товарах в БД. То есть для каждого товара хранится строчка "характеристики ... действует с ... действует по". Изменение характеристик приводит к появлению новой строчки, "удаление товара" — к закрытию последней строчки сегодняшней датой. Ну а заказ ссылается на конкретную строчку и никак не меняется вне зависимости от того, что там за другие строчки появляются.
Однако, если это не курсовая, таки советую обратить пристальное внимание на предыдущий пост про взаимоотношения товара, магазина и склада. "На самом деле" там всё непросто и нуждается в тщательном продумывании, иначе Ваша софтина сгодится разве что как способ отправить главбуха в места не столь отдалённые
Здравствуйте, Softwarer, Вы писали:
S>Здравствуйте, Аноним, Вы писали:
А>>Как это правильнее реализовать с точки зрения проектирования БД?
S>Именно это так как написано правильнее всего реализуется версионностью информации о товарах в БД. То есть для каждого товара хранится строчка "характеристики ... действует с ... действует по". Изменение характеристик приводит к появлению новой строчки, "удаление товара" — к закрытию последней строчки сегодняшней датой. Ну а заказ ссылается на конкретную строчку и никак не меняется вне зависимости от того, что там за другие строчки появляются.
С точки зрения "правильного" строения базы это хорошо, но с точки зрения производительности гораздо лучше пойти на денормализацию и хранить цену в заказе (или накладной). Иначе простые запросы типа "верните мне все заказы вот этого клиента" приведут к перелопачиванию всей таблицы с товарами, которая может быть немаленькая.
Шурыгин Сергей
"Не следует преумножать сущности сверх необходимости" (с) Оккам
Здравствуйте, Sshur, Вы писали:
S>С точки зрения "правильного" строения базы это хорошо,
Именно.
S>но с точки зрения производительности гораздо лучше пойти на денормализацию и хранить цену в заказе (или накладной). Иначе простые запросы типа "верните мне все заказы вот этого клиента" приведут к перелопачиванию всей таблицы с товарами, которая может быть немаленькая.
Ну, насчёт "перелопачивания" — это большое преувеличение
Если мы говорим о реальной работе, то "денормализация" здесь нужна не с точки зрения производительности, а прежде всего с точки зрения корректности учётной информации. Если мы продали бутылку водки по цене 100 рублей — это объективный факт, который должен быть отражён в БД и совершенно не зависит от того, что там в это самое время руководитель отдела продаж счёл опечаткой и правит в базе. Кроме того, на итоговую цену продажи действуют всяческие скидки, акции, спецусловия, что в итоге делает "ссылку на прайс" пригодной только для курсовой. О чём сразу и было сказано.
Здравствуйте, Аноним, Вы писали:
А>Добрый день,
А>Хотелось бы выслушать идеи или готовые паттерны для следующего случая:
А>Имеется магазин и список товаров. У товара есть хар-ки (цена, название). Пользователь приобретает товар. Информация о заказе сохраняется в базу. При изменении стоимости товара в заказе должна оставаться прежняя цена. Так же при удалении товара заказ тоже должен оставаться.
А>Делать отдельную таблицу "заказ" не связанную с таблицей "товар" и хранить там данные, актуальные на момент заказа?
Да, лучше создать отдельную таблицу для заказов, в которой и хранить значения атрибутов товара на момент покупки. Недавно я как раз закончил разработку модели данных для веб-магазина. У нас, например, для каждой позиции заказа хранится следующая информация:
— Название товара (внутреннее, используемое администратором магизина, и внешнее, переведенное на язык покупателя)
— Название варианта товара
— Все атрибуты товара — цвет, размер и т.д. — тоже внутренние и переведенные.
— Цена
— Информация о налоге с оборота
— Информация о скидках и акциях
— Вес товара
— Информация о веб-магазине,продавшем товар
— Информация о позиции каталога, из которой продан товар
— Информация о взаимосвязях между отдельными товарами внутри заказа
— Информация о возврате товара
При этом также хранится ссылка на товар из таблицы "товары", но если товар удален оттуда, то в таблице заказов ссылка на него заменяется на NULL.
Для заказа в целом:
— Информация о доставке (метод, цена и т.д.)
— Информация об упаковке для доставки
— Полная информация о процессе платежа
Изображения товара не хранятся
На самом деле у нас не одна таблица для заказов, а 5.
