Mysql 这些桌子我设计得对吗？

下面是一个场景…一个人可以有一个用户记录，有或没有关联的配置文件记录。此人还可以拥有他/她“管理”的多个个人资料（家庭成员等），这些个人资料可能有也可能没有与之关联的用户记录，因为他们可能使用或可能不使用网站/应用程序

档案记录包含个人信息，如姓名、出生日期等。。。因此，我们可以拥有史密斯奶奶的个人资料，但没有相关的用户记录，因为她自己永远不会使用该网站，只有她的女儿会使用

下面列出了重要字段（这是一组正确规范化的表吗？）

用户：id、电子邮件、密码、配置文件id（FK，可空）

用户配置文件：id，用户id，配置文件id

配置文件：id、名称、dob、用户id（FK，可为空）

---

我想我想知道的是，如果我有一个profile\u id外键和一个user\u id外键，这些是多余的吗？在我的网站上，我有一个个人资料编辑页面，您可以在同一页面上编辑一个人的用户信息和个人资料信息，因此我希望能够从引用页面提供个人资料ID或用户ID，并调出相应的数据。如果配置文件记录中没有用户id，则很难确定当前配置文件是否有用户记录。

如果我正确理解了表结构，则配置文件id看起来是多余的。用户id是指向配置文件的链接，它作为外键驻留在用户id中

至于你是如何质疑它的。。。我有点担心。您是否应该要求用户id，然后允许用户查看和编辑所有关联的配置文件？这似乎符合当前的实践，应该可以解决您的两难问题，即在用户中必须有profile_id

---

尽管如此，即使您保持当前设置，用户id也可以用于查询配置文件，配置文件id也可以用于查询配置文件，因此您可以任意设置。

每个表中的“id”字段仅是PK自动递增字段。Profiles.user_id是指向Users.id的FK。我也没有提到User_Profiles表，它是保存给定用户下的配置文件的地方。因此，单个用户可以有一个描述此人的配置文件，或者在他们管理的配置文件的user_Profiles表中有条目。为了回答您的问题，profiles表中的user\u id字段实际上指向直接连接到该配置文件的用户。因此profiles是用户的配置文件，而user\u profiles是用户管理的配置文件，对吗？那么用户自己的配置文件将不在用户配置文件中？我这样问是因为如果用户自己的配置文件在User_Profiles中，您可以去掉UserProfiles.User_id，因为User_Profiles.profile_id足以获取配置文件和用户（假设Profiles.id是配置文件的主键）。换句话说，您的所有配置文件都可以放入一个配置文件表中，您可以通过将id放入另一个表（ala集合成员身份）来标记特殊配置文件。不，用户自己的配置文件在用户中引用。配置文件id，它将不在用户配置文件中。为什么不添加它并简化您的表？基本上，您可以按照ID来获得您想要的。这可能会使您的查询变得有些复杂，但会减少冗余。因此，您的意思是从用户中删除profile\u id，从配置文件中删除user\u id，并简单地为用户自己在user\u配置文件中添加一条记录？最终的答案是重写如下表：user:（id…）profiles:（id，user\u id…）owner:（profile\u id）