我目前正在使用我的团队中的其他人设计的数据库，他使用的是我之前没有遇到过的数据库设计风格。我想知道以下设计是不是很好的做法，因为它对我来说似乎很麻烦。
有一个正常的＆＃39;包含用户和业务特定信息的数据库。对于＆＃39;类型＆＃39;在此数据库中，例如user，在两个单独的数据库中存在一个表，即status和types。
用户的状态只是名称和描述（例如有效或已删除）。
users的类型对我来说并不是很清楚，但该表包含名称，描述，子集和级别字段。
繁琐的部分是这些表的链接，因为它们存在于不同的数据库中，user表需要状态和类型的键（不能通过外键强制执行）。
最好有一个简单的布尔字段来指示用户是否处于活动状态，对于类型，如果有任何不可能的话，是否使用继承？
答案 0 :(得分：1)
这些用户可能是初学者，因此您可以决定是否在代码中检查您的用户状态，例如当您登录时，如果查询具有以下内容：where status = 'active'或者像这样，那么在这种情况下您不会需要一个表，用户状态是您可以包含在源代码中的静态值，如果您的系统支持多语言，您还应该考虑这些状态的语言。与类型字段相同。
但是如果您不需要在代码中检查这些标志，那么将它们保留在表中是没有问题的，但在这种情况下，为了让用户能够在此之后添加类型或状态会很好。
答案 1 :(得分：1)
我认为您的问题涉及两个不同方面：
1）数据内聚和完整性 - 引用来自其他表的数据，这些表可以在同一个数据库中，也可以不在同一个数据库中
2）规范化 - 我是否需要其他表中的状态和类型，或者它们可以合并到同一个表中？
1）如果您没有处理大量数据（至少数千万条记录），我建议在＆＃34; normal＆＃34;中复制status和types表。数据库。如果来自那里的数据很少改变，则特别推荐这一点。
这样做可以应用参照约束（FK）并且速度更快JOIN。
2）虽然它增加了一些复杂性（额外的表格，定义约束等），但将数据标准化可能会带来一些重要的优势：
灵活性 - 如果添加了状态或类型，则只表示在表格中进行简单插入
较小的表 - users表只存储一些状态和类型的ID，而不是字符串或难以猜测的值（例如0 - 不活动，1 - 活动等）
更容易维护 - 更改了类型名称？只需更新表格中的记录
标准化结构通常如果设计得恰当（PK，FK，检查约束等）并且允许分离关注点（可能在将来某个时候为用户类型实现设计器），
通常，数据库分离应基于活动类型：
INSERT s旁边有UPDATE个，DELETE个，SELECT个SELECT s）ETL目的地 - 重INSERT s，UPDATE等