MySQL DB 的设计以避免出现具有互斥字段的表
我正在创建一个新的数据库,但遇到了这个问题:我有两种类型的用户可以下订单:注册用户(即他们有登录名)和访客用户(即没有登录名)。注册用户和来宾用户的数据不同,这就是为什么我考虑使用两个不同的表,但订单(共享相同的工作流程)都是相同的,所以我考虑只使用一张表。
我已阅读此处和这里(即使我不完全理解这个例子)我可以强制执行MySQL规则以在表中包含互斥的列(在我的例子中,它们会是“idGuest”和“idUser”),但我不喜欢这种方法。
有更好的方法吗?
I'm creating a new DB and I have this problem: I have two type of users that can place orders: registered users (that is, they have a login) and guest users (that is, no login). The data for registered users and guest users are different and that's why I'm thinking of using two different tables, but the orders (that share the same workflow) are all the same, so I'm thinking about using only one table.
I've read here and here (even if I don't understand fully this example) that I can enforce a MySQL rule to have mutually exclusive columns in a table (in my case they'd be "idGuest" and "idUser") but I don't like that approach.
Is there a better way to do it?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
有多种方法,这取决于记录的数量和唯一字段的数量。例如,如果您说它们只有两个字段不同,我会建议您将所有内容放在同一个表中。
假设它们有很大不同,我的方法是思考“对象”:
您有一个主用户表,对于每种用户类型,您都有另一个“详细说明”该用户信息的表。
其中 user_id 是
users
表的外键There are several approaches, which depends on the number of records and number of unique fields. For example, if you would say they differ in only two fields, I would have suggested that you just put everything in the same table.
My approach, assuming they differ a lot, would be to think "objects":
You have a main user table, and for each user type you have another table that "elaborates" that user info.
Where user_id is foreign key to
users
table听起来主要是一个关系超类型/子类型问题。我已经回答了类似的问题,并包含了示例代码,您应该能够轻松适应。 (请务必阅读评论。)
对您来说稍微复杂的因素是一种子类型(来宾用户)有一天可能会变成另一种子类型(注册用户)。您如何处理这将取决于应用程序。 (这意味着你会知道,但可能没有其他人知道。)
Sounds like mostly a relational supertype/subtype issue. I've answered a similar question and included sample code that you should be able to adapt without much trouble. (Make sure you read the comments.)
The mildly complicating factor for you is that one subtype (guest users) could someday become a different subtype (registered users). How you'd handle that would be application-dependent. (Meaning you'd know, but probably nobody else would.)
我想我会有三个表:
user
表,其中包含:已注册
表,其中包含:然后,当引用用户时(例如,在您的
orders
表中),您可以始终使用user
表的 ID。I think I would have three tables :
user
table, that would contain :guest
table, that would contain :registered
table, that would contain :Then, when referencing a user (in your
orders
table, for example), you'd always use the id of theuser
table.您所描述的是一个多态表。听起来很可怕,但实际上并没有那么糟糕。
您可以保留单独的用户表和来宾表。对于您的 Orders 表,您有两列:
foreign_id
和foreign_type
(您可以将它们命名为任何名称)。foreign_id
是您的情况下用户或访客的 ID,foreign_type
的内容将是user
或guest
:要为特定用户或访客选择行,只需指定
foreign_type
以及 ID:What you are describing is a polymorphic table. It sounds scary, but it really isn't so bad.
You can keep your separate User and Guest tables. For your Orders table, you have two columns:
foreign_id
andforeign_type
(you can name them anything). Theforeign_id
is the id of the User or Guest in your case, and the content of theforeign_type
is going to be eitheruser
orguest
:To select rows for a particular user or guest, just specify the
foreign_type
along with the ID:Orders 表中指向下订单的 Customer 实体的外键通常是不可为 null 的列。如果您有两个不同的客户表(RegisteredCustomer 和 GuestCustomer),那么您将需要 Orders 表中的两个单独的可空列指向单独的客户表。我建议只包含一个 Customers 表,仅包含注册用户和来宾用户常见的行(编辑:抱歉,只写那些列),然后是具有外键关系的 RegisteredUsers 表与客户表。
The foreign key in the Orders table pointing back to the Customer entity that placed the order is typically a non-nullable column. If you have two different Customer tables (RegisteredCustomer and GuestCustomer) then you would requiree two separate nullable columns in the Orders table pointing back to the separate customer tables. What I would suggest is to have only one Customers table, containing only those rows (EDIT: sorry, meant to write only those COLUMNS) that are common to registered users and guest users, and then a RegisteredUsers table which has a foreign-key relationship with the Customers table.