电子商务不同购物车项目数据库和数据库模型设计
我有一个电子商务网站，有两种类型的产品：书籍和书籍。研讨会的参与。 它们是不同的，并且具有不同的属性。 我很好奇你如何在数据库中对此进行建模并作为模型（因为你不能继承多个类）
现在我有类似的东西： DB
products (id, name ....)
seminars (id, title, date ....)
cart (id, session_id ...)
cart (id, cart_id, type, id_model) the type is product OR seminar
至于模型，我有一个
cart_item_abstract
cart_item_product -> cart_item_abstract
cart_item_seminar -> cart_item_abstract
cart_order_product -> cart_item_product
cart_order_seminar -> cart_item_seminar
但这意味着我必须复制订单对象所需的一些代码。
I have a ecommerce site that has 2 types of products: books & seminars participations.
They are different, and have different attributes.
I am curious how would you model this in the DB and as models (since you cannot inherit multiple classes)
Right now i have something like:
DB
products (id, name ....)
seminars (id, title, date ....)
cart (id, session_id ...)
cart (id, cart_id, type, id_model) the type is product OR seminar
as for models i have a
cart_item_abstract
cart_item_product -> cart_item_abstract
cart_item_seminar -> cart_item_abstract
cart_order_product -> cart_item_product
cart_order_seminar -> cart_item_seminar
But that means i have to duplicate some of the code required by order objects.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您应该在 google 上搜索“继承映射”，这一切都可以归结为这些选择：
选择取决于具体要求 - 性能与简单性等。
You should google for Inheritance Mapping", it all boils down to these choices:
The selection depends on specific requirement - performance vs. simplicity, etc.
一种方法是简单地创建一个产品模型，供书籍和研讨会等参考。因此，书籍和研讨会的每条记录都有一个product_id 引用。
就您的购物车代码而言，您主要只关心product_id、标题和价格。
您的目录代码更关心差异，但您对书籍的浏览/显示处理方式与对研讨会注册的处理方式不同。但两者都有产品 ID，因此如果您的用户“添加到购物车”，您只需告诉购物车“添加产品 ID #123”即可。对 LEFT JOIN 和条件进行一些巧妙的思考应该可以让购物车轻松计算出任何给定产品 ID 的标题和成本，无论其类型如何。
希望这有帮助。
One approach would be to simply create a product model, which things like books and seminars reference. So each record for both books and seminars has a product_id reference.
As far as your shopping-cart code is concerned, you mostly just care about a product_id, title, and price.
Your catalog code cares more about the differences, but you handle browsing/display differently for books than you do for seminar registrations. But both have a product ID, so if your user "add to cart"s, you just tell the cart "add product id #123". A little clever thinking about LEFT JOINs and conditionals should make it easy for the cart to figure out the title and cost for any given product ID, regardless of it's type.
Hope this helps.
您是否考虑过您的继承模式可能存在缺陷？
我认为购物车可以包含一个或多个商品，并且一旦用户完成购物车中所有商品的购买，就会创建订单。因此，一个订单同样会包含多个项目。
考虑到这一点，您可以使用继承映射创建一个表，其中包含项目类型以及类型字段（研讨会、产品）之间常见的所有值。然后，为每种类型创建一个表来保存唯一值。
您的基本项目类应该实现一组多态接口，这些接口将返回正确的值，例如项目名称、项目描述，但需要在各个子类中实现不同的实现。
举个例子，我最近从事一个项目，如果用户是管理员或雇主，我需要返回名称的用户名，如果用户是学生，我需要返回名字和姓氏连接。我创建了一个返回适当值的函数 _getName()，并且使用它的代码（在本例中为视图）不必执行任何上下文处理。
您的购物车和订单课程也应该如此。他们应该能够与产品和研讨会类进行交互，而无需执行任何上下文处理。
Have you considered that your inheritance pattern may be flawed?
I would think that a cart could contain one or more items and that an order would be created once a user had completed the purchase of all items in the cart. So an order would likewise contain multiple items.
With that in mind you could use Inheritance Mapping to create a single table that holds all of the values that are common between item types as well as a type field (seminar, product). Then you create a table for each type to hold the unique values.
Your base item class should implement a set of polymorphic interfaces that will return the proper values such as Item Name, Item Description but will require different implementations in the various subclasses.
As an example, I recently worked on a project where I needed to return the user name for a name if the user was an admin or employer and I needed to return the first and last name concatenated if the user was a student. I created a function _getName() that returned the appropriate value and the code using it (in this case the view) didn't have to do any contextual processing.
It should be likewise with your Cart and Order classes. They should be able to interact with the Product and Seminar classes without having to perform any contextual processing.
在您的数据库中，您不能只有两张表，一张用于产品（id，类型，价格，标题），然后是属性（id，product_id，attribute，description）？
这样您就可以在产品与属性之间建立一对多的关联。
在您的购物车模型中，您可能只有一个 get-product() 方法，该方法仅返回产品 ID、标题和价格。
在用于实际显示目录中产品的模型中，您还可以使用 get-product() 方法（或 get-product-attribute($product-id) ）方法，但要返回产品表中的值，并且按照蒂姆的建议，属性表带有左连接。
In your DB couldn't you only have two tables, one for products(id, type, price, title) then and attributes(id, product_id, attribute, description)?
That way you could have a one to many association between your products to attributes.
In your shopping cart model you could have just have a get-product() method that would return just the product id, title and price.
In your model for actually displaying the products in your catalogue you could also have a get-product() method (or a get-product-attribute($product-id) ) method, but have that return the values from the products table and the attributes table with a left join as tim suggested.