为具有多个用户类型的场景设计数据库
为具有多个用户类型的场景设计数据库
提问于 2016-08-10 09:09:27
我正在从事一个具有多个用户类型的项目，如Contributor、Student、Sales、CS、Operator等。我通常将它们分成不同的表，对于每个实体(即Authenticable )，我创建了一个名为Credentials的表，该表具有一对一的关系。
我的问题是：
- 在处理像这样的“可验证”的多个用户时，最佳实践是什么？
- 我的设计有哪些不足之处？
- 是否有必要将
Username和Password“移动”到每种类型的User实体中？
谢谢你的帮助。如果我的问题很难理解，请给我一个建议，因为我不是英语专家。
回答 1
Database Administration用户
发布于 2016-08-10 10:06:53
我不相信有一个最好的设计适合所有的情况。这一切都取决于您正在努力执行的业务规则。如果所有类型都共享相同的属性，那么最好使用一个带有分类器属性的表。在光谱的另一端，存在类型不共享属性的情况(在您的情况下不太可能)。
通常情况下，可以在公共表中表示一组公共属性，例如：
CREATE TABLE ORGANISATIONS -- I just invented a name here
( ORGANISATION_ID ... NOT NULL PRIMARY KEY
, ORGANISATION_TYPE ... NOT NULL
, <other attributes>
, CONSTRAINT ... CHECK ORGANISATION_TYPE IN (...)
);然后是一组表，这些表表示并非所有类型都通用的属性：
CREATE TABLE CONTRIBUTORS
( ORGANISATION_ID ... NOT NULL PRIMARY KEY
, <other attributes>
, CONSTRAINT ... FOREIGN KEY (ORGANISATION_ID)
REFERENCES ORGANISATIONS (ORGANISATION_ID)
);SQL99 (甚至可能是SQL92，不确定)允许在CHECK约束中进行选择，因此我们可以添加一个CHECK约束，它可以保证信息与组织中的organisation_type相对应。但是，没有多少供应商实现这一点，因此一种常见的方法是“继承”类型属性。首先，在组织中添加一个超级密钥：
ALTER TABLE ORGANISATIONS ADD CONSTRAINT AK1_ORGANISATIONS
UNIQUE (ORGANISATION_ID, ORGANISATION_TYPE);然后将type属性添加到“子表”中：
CREATE TABLE CONTRIBUTORS
( ORGANISATION_ID ... NOT NULL PRIMARY KEY
, ORGANISATION_TYPE ... NOT NULL
, <other attributes>
, CONSTRAINT ... FOREIGN KEY (ORGANISATION_ID,ORGANISATION_TYPE)
REFERENCES ORGANISATIONS (ORGANISATION_ID,ORGANISATION_TYPE)
, CONSTRAINT ... CHECK ORGANISATION_UNIT_TYPE IN (...) -- subset of types in ORGANISATIONS
)check约束和外键保证使用正确的类型。
注意，如果一个表(如贡献者)具有一组共同的属性，则它们可以用于两种或多种类型。为了向这些类型添加其他属性，可以使用相同的技术。
另一种方法是在不适用的情况下使用可空属性。根据我的经验，它很快就会变得凌乱，而且我只会在很少有这样的属性的情况下使用它。
页面原文内容由Database Administration提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://dba.stackexchange.com/questions/146344
复制相关文章
相似问题
腾讯云开发者
