Как сохранить копии заказанных товаров в интернет-магазине?

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

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

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

Когда кто-то совершает покупку, вы записываете идентификатор продукта и идентификатор истории/версии продукта в таблицу покупок.

При таком типе настройки истории вы нормализуете данные о продукте, поэтому они не сохраняются снова и снова с каждой записью о покупке, и вы по-прежнему можете получать конкретные сведения о каждой покупке.

При сохранении информации «во время покупки» рекомендуется указывать только ссылку на артикул --- но на самом деле копировать всю информацию из таблицы продуктов (включая цену, описание, артикул и т. д.). В случае, если в будущем описание продукта и цены изменятся, ваши заказы не будут нарушены.

Обычно я связываю продукт по идентификатору продукта, а затем также копирую все данные о продукте в детали заказа.

Точно так же вы захотите сделать то же самое между учетными записями ‹--> Заказы. Свяжите заказ с идентификатором учетной записи, но сохраните всю фактическую информацию о клиенте (имя, адрес и т. д.), чтобы ее нельзя было оспорить позже, если она была изменена и т. д.

Вам не придется беспокоиться о том, какая версия этого артикула была настроена — какой бы она ни была в то время, она была такой, и именно за нее выставлялся счет. Таким образом, вся предыдущая история клиента остается в силе.

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

Вышеизложенное — это то, что я видел в таких системах, как SAP B1, и шаблон проектирования имеет смысл. Для хранения некоторой дополнительной информации вы избавляетесь от сложности в другом месте.

Как правило, в эко-магазине есть следующие таблицы:

accounts
products
order
orderdetails

Обычно это намного больше. Но это база.

Account = the user shopping in the store
Product = the product description, price, etc.
Order = the high level order details such as purchase date, shipping/billing address
OrderDetails = the low level order details such as price at time of purchase, quantity, etc.

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

Идея Jas Panesar относительно SKU довольно хороша. Однако, если вы ищете более простой подход, вы можете сохранить информацию в массиве, сериализовать ее, а затем сохранить сериализованный результат в одном поле в вашей базе данных.

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