MySQL DB 的设计以避免出现具有互斥字段的表

发布于 2024-10-21 14:27:02 字数 536 浏览 1 评论 0原文

我正在创建一个新的数据库,但遇到了这个问题:我有两种类型的用户可以下订单:注册用户(即他们有登录名)和访客用户(即没有登录名)。注册用户和来宾用户的数据不同,这就是为什么我考虑使用两个不同的表,但订单(共享相同的工作流程)都是相同的,所以我考虑只使用一张表。

我已阅读此处这里(即使我不完全理解这个例子)我可以强制执行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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

冰火雁神 2024-10-28 14:27:02

有多种方法,这取决于记录的数量和唯一字段的数量。例如,如果您说它们只有两个字段不同,我会建议您将所有内容放在同一个表中。
假设它们有很大不同,我的方法是思考“对象”:
您有一个主用户表,对于每种用户类型,您都有另一个“详细说明”该用户信息的表。

Users
-----

id,email,phone,user_type(guest or registered)

reg_users
---------

users_id, username,password etc.....

unreg_users
-----------

user_id,last_known_address, favorite_color....etc

其中 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.

Users
-----

id,email,phone,user_type(guest or registered)

reg_users
---------

users_id, username,password etc.....

unreg_users
-----------

user_id,last_known_address, favorite_color....etc

Where user_id is foreign key to users table

云朵有点甜 2024-10-28 14:27:02

听起来主要是一个关系超类型/子类型问题。我已经回答了类似的问题,并包含了示例代码,您应该能够轻松适应。 (请务必阅读评论。)

对您来说稍微复杂的因素是一种子类型(来宾用户)有一天可能会变成另一种子类型(注册用户)。您如何处理这将取决于应用程序。 (这意味着你会知道,但可能没有其他人知道。)

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.)

蓝天白云 2024-10-28 14:27:02

我想我会有三个表:

  • 一个 user 表,其中包含:
    • 每个用户占一行,无论用户类型如何
    • 为访客和注册者提供的数据
    • 指示一行是否对应于已注册或访客的字段
  • 字段 访客表,其中将包含:
    • 每个访客用户一行,
    • 特定于客人的数据
  • 和一个已注册表,其中包含:
    • 每个注册用户一行,
    • 特定于注册用户的数据

然后,当引用用户时(例如,在您的 orders 表中),您可以始终使用 user 表的 ID。

I think I would have three tables :

  • A user table, that would contain :
    • One row for each user, no matter what type of user
    • The data that's present for both guests and registered
    • A field that indicates if a row corresponds to a registered or a guest
  • A guest table, that would contain :
    • One row per guest user,
    • The data that's specific to guests
  • And a registered table, that would contain :
    • One row per registered user,
    • The data that's specific to registered users

Then, when referencing a user (in your orders table, for example), you'd always use the id of the user table.

つ可否回来 2024-10-28 14:27:02

您所描述的是一个多态表。听起来很可怕,但实际上并没有那么糟糕。

您可以保留单独的用户表和来宾表。对于您的 Orders 表,您有两列:foreign_idforeign_type(您可以将它们命名为任何名称)。 foreign_id 是您的情况下用户或访客的 ID,foreign_type 的内容将是 userguest

id  |  foreign_id  |  foreign_type  |  other_data
-------------------------------------------------
1   |  1           |  user          |  ...
2   |  1           |  guest         |  ...

要为特定用户或访客选择行,只需指定 foreign_type 以及 ID:

SELECT * FROM orders WHERE foreign_id = 1 AND foreign_type = 'guest';

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 and foreign_type (you can name them anything). The foreign_id is the id of the User or Guest in your case, and the content of the foreign_type is going to be either user or guest:

id  |  foreign_id  |  foreign_type  |  other_data
-------------------------------------------------
1   |  1           |  user          |  ...
2   |  1           |  guest         |  ...

To select rows for a particular user or guest, just specify the foreign_type along with the ID:

SELECT * FROM orders WHERE foreign_id = 1 AND foreign_type = 'guest';
毅然前行 2024-10-28 14:27:02

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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文