Question

描述此场景的最佳方法是使用示例。考虑一下Netflix：做到了将他们的订单（他们邮寄出来的DVD）存储在一个单独的表中，其成员列表（不是会员表，但是成员和电影的连接表 - 每个成员创建的电影列表），或者通过在同一个表的同一行中使用其他信息来区分订单吗？

对于那些不熟悉Netflix的人，想象一下可以创建电影愿望清单的服务。此愿望清单随后会逐渐发送给您，一次说两部电影。

我想使用MySQL数据库实现类似的想法，但我不确定是否要创建两个表（一个用于订单，一个用于列表）并动态地将项目从列表移动到订单表（此过程应该根据退回项目的成员进行半自动，在发送新项目之前，将检查具有某些控件的表格，以查看用户是否仍有资格/未超过其月度限制）... < / p>

思想和利弊会很棒！

编辑：我当前的架构是：member，items，members_items，我要问的是如果将订单存储在与members_items相同的表中，或者创建一个单独的表。

Answer 1

在成员表中存储订单的一个问题是每个成员的订单数量可变（0,1或几个）。使用关系数据库执行此操作的方法是使用两个单独的表。

Answer 2

将事物从一个数据库表移动到另一个数据库表以改变其状态只是不好的做法。在RDBMS中，使用主键和外键约束将一个表中的行与其他表中的其他行相关联。

至于你的例子，我看到了四张桌子才刚刚开始。与电影租赁的祖父Netflix相比，这与现实相去甚远。请记住这一点。

电影表格中的电影状态可能在另一个表格中，您将用户与电影关联到MovieStatus或其他内容，这会将您的桌面数量设置为6.要真正做到这一点并正确设计，您可以最终会有更多，但希望这种方式让你知道从哪里开始。

编辑：看到您正在寻找的确切内容的更新。我以为你是从零开始设计的。你问题的简单答案是：有两张桌子。 Wishlists（或者你拥有的member_items）和Orders（member_orders？）根本不同，所以保持它们分开是我的建议。

Answer 3

我觉得他们会将电影存储如下（当然简化）：

表：

这样一个拥有成员外键的订单就会有一个数据透视表，因为很多订单可能有很多标题。

当您在数据库中有多对多的实际情况时，您需要创建一个数据透视表：

Order_Has_Titles:
    ID (auto-inc)
    Order_FkId (int 11)
    Title_FkId (int 11)

通过这种方式，您可以在每个订单中放置多部电影。

当然这是简化的，你会有很多其他的组件，但是在基础层面，你可以在这里看到它。