如何在网上商店中保留订购商品的副本？
人们在网上商店购买东西。
我接受他们的订单并将其保存到数据库中。 对于每个订购的商品，我需要该商品的数量和信息。 至少，我需要保存每件商品的当前价格和名称，但我真的更愿意保存所有内容。
问题来了...保留每个订购商品的所有信息与购买时的信息保持一致的最佳方法是什么？
- 复制到与产品表具有相同列的单独表中
- 在同一个表中制作产品副本，标记为不可编辑、不可查看的副本
- 某种写模式复制可以节省一些空间，直到“实时”产品信息实际更改？
- ????
为简单起见，我们假设所有产品信息都保存在一个表中。
People buy stuff in a web shop.
I take their orders and save them to a database. For each ordered item, I need the quantity and the information about the item. At the very least, I'm going to need to save the current price and name of each item but I would really prefer to save everything.
And here comes the question... What's the best way to keep all the information about each ordered item as it was at the time of purchase?
- Copy into a separate table with the same columns as the product table
- Make copies of products in the same table, marked as non-editable, non-viewable copies
- Some sort of copy on write schema that saves some space until the "live" product information is actually changed?
- ????
For simplicity, let's assume all product information is kept in a single table.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
如果您商店中的产品要经常更改，那么听起来您需要的是产品版本历史记录。
基本上，您应该尝试识别商店商品中经常更改的所有属性/字段，并将它们放入单独的
product_properties（或其他）表中，并带有该特定版本的时间戳这些属性。 也许您的所有属性都会随时发生变化，在这种情况下您可能只需要一张表。 无论如何，您可以假设最新的时间戳是该产品的最新版本。当店主更新产品时，您可以在
product_properties中创建一条包含所有已更改属性的新记录，并更新主产品表记录以指向该新记录（或者只是提取最新的时间戳）在显示时）。当有人购买时，您在购买表中记录产品 id 和产品的历史/版本 id。
通过这种类型的历史记录设置，您已经标准化了产品数据，因此它不会与每个购买记录一起反复存储，并且您仍然可以获得每次购买的具体详细信息。
If the products in your shop are going to change frequently, then it sounds like what you need is a product version history.
Basically, you should try to identify all the properties/fields of your shop items that are going to frequently change, and put them into a separate
product_properties(or something) table, with a timestamp for that particular version of those properties. Perhaps all your properties will change all the time, in which case you might get away with a single table. In any event, you can assume that the newest timestamp is the latest version of the product.When the shop owner updates a product, you create a new record in
product_propertieswith all the changed properties, and update the main product table record to point to this new record (or simply just pull out the newest timestamp at display time).When someone makes a purchase, you record the product id and the history/version id of the product in the purchase table.
With this type of history setup, you've normalized the product data, so it's not stored over and over again with each purchase record, and you can still get the specific details of each purchase.
在存储“购买时信息”时，最好只链接到一个 sku，但实际上复制产品表的所有信息（包括定价、描述、sku 等）。 如果将来产品描述和价格发生变化，您的订单也不会中断。
我通常通过产品 ID 链接产品，然后将所有产品数据复制到订单详细信息中。
同样，您需要在帐户之间执行相同的操作<--> 命令。 将订单链接到帐户 ID，但存储所有实际客户信息（姓名、地址等），以便以后如果更改等情况不会出现争议。
您不必担心此 sku 的版本它的设置是——无论当时是什么，就是这样，这就是计费的。 这样，客户过去的所有历史记录都保持有效。
如果您想要另一层，您可能需要对帐户和产品表实施跟踪更改，以便您知道何时更改了哪些内容。
以上是我在 SAP B1 等系统中看到的内容，设计模式是有意义的。为了存储一些额外的信息，您可以摆脱其他地方的复杂性。
It is a good idea when storing the "at the time of purchase info" to only link to a sku --- but actually copy in all the information of the product table (including pricing, description, sku, etc). In case in the future those product description and pricing changes, the orders you have won't break.
I normally link the product in by product ID and then also copy in all the product data into the order detail.
Likewise, you will want to do the same between Accounts <--> Orders. Link an order to account ID, but store all of the actual customer information (name, address, etc) so it can't be disputed later if it was changed, etc.
You won't have to worry about which version of this sku it was setup as -- whatever it was at the time, it was, and that's what was billed. That way all of a client's past history stays in effect.
If you want another layer you might want to implement tracking changes to the account and product tables so you know what was changed when.
The above is what i have seen in systems like SAP B1 and the design pattern makes sense.. For storing some extra information you get rid of the complexity elsewhere.
一般来说，电子商务商店有以下表格：
通常还有更多内容。 但这是基础。
查看 DashCommerce 等开源购物车，以了解如何设置工作购物车系统。 我喜欢这个特别的，因为它实现了许多必需的且更复杂的电子商务！
Generally an ecom store has the following tables:
There usually is a lot more to this. But this is the base.
Take a look at an open source shopping cart such as DashCommerce to get a good idea of how a working cart system is set up. I like this particular one as it implements many of the required and more complex of ecommerce!
Jas Panesar 的 SKU 想法非常好。 但是，如果您正在寻找一种更简单的方法，则可以将信息存储在数组中，将其序列化，然后将序列化结果存储在数据库中的单个字段中。
虽然这不像解决方案那样强大，但它确实使您能够快速轻松地获取信息，而无需重新设计整个数据库结构。
Jas Panesar's idea of a SKU is quite a good one. If however, you're looking for a simpler approach, you could store the information in an an array, serialize it, and then store the serialized result in a single field in your database.
While this isn't as robust as a solution, it does give you the ability to quickly and easily grab information without redesigning your whole database structure.