哪个数据库表架构更有效，为什么？

"Users (UserID, UserName, CompamyId)"
"Companies (CompamyId, CompanyName)"

或者

"Users (UserID, UserName)"
"Companies (CompamyId, CompanyName)"
"UserCompanies (UserID, CompamyId)"

考虑到用户和公司之间存在一对一的关系。

解决方案

回答

可以肯定的是，考虑到该约束，较早的方法效率更高。为了获得相同的信息，查询中的联接数将减少。

回答

好吧，这是一个开放式问题，取决于业务规则。我们拥有的第一个选项仅允许将一个公司映射到一个用户。我们正在定义多对一关系。

第二个模式定义了多对多关系，该关系允许将多个用户映射到多个公司。

他们解决了不同的问题，根据我们要解决的问题，将确定我们应该使用哪种架构。

从"交易"的角度严格来说，第一个模式会更快，因为我们只需为用户对象提交一行即可与公司建立关联，而检索用户所在的公司只需一个联接，但是，如果业务需求发生变化并要求我们有多个公司隶属于一个用户，则第二个解决方案将更好地扩展。

回答

一如既往，这取决于。我个人会选择第一个答案，因为它的联接较少，维护起来也更容易。较少的联接应该意味着它需要较少的表和索引扫描。

SELECT userid, username, companyid, companyname
FROM companies c, users u
WHERE userid = companyid

比...好得多

SELECT userid, username, companyid, companyname
FROM companies c, users u, usercompanies uc
WHERE u.userid = uc.userid
AND c.companyid = uc.companyid

回答

我认为对于用户和公司，意思是"一对多"，除非我们计划为每个用户建立一个独特的公司。

要回答问题，请采用第一种方法。少存储一张表可减少空间，并使查询使用更少的JOIN命令。而且，更重要的是，它正确匹配我们所需的输入。数据库模式应描述所有有效数据的格式(如果适合该格式，则应将其视为有效)。由于用户只能拥有一个公司，因此如果我们使用第二个架构，则数据库中的数据可能不正确。

回答

不能比较这两种模式，因为它们具有不同的关系，因此我们应该仔细查看表的规格，然后确定哪种模式适合所需的关系。

第一个暗示用户只能是一个公司的成员(belongs_to关系)。而第二种模式意味着用户可以是许多公司的成员(has_many关系)

如果我们正在寻找一种可以(或者以后支持)has_many关系的模式，那么我们想选择第二种。出于原因比较：

//select all users in company x with schema 1
select username, companyname from companies
inner join users on users.companyid = companies.companyid
where companies.companyid = __some_id__;

和

//select all users in company x with schema 2
select username, companyname from companies
inner join usercompanies on usercompanies.companyid = companies.companyid
inner join users on usercompanies.userid = users.userid
where companies.companyid = __some_id__;

我们在选择表上有一个额外的联接。如果我们只希望自己的归属关系，则第二个查询的工作量将超出其应有的范围，从而使效率降低。

回答

如果用户和公司确实存在一对一的关系，那么我们只需要一个表：

(ID, UserName, CompanyName)

但是我怀疑意思是，用户和公司之间存在一对多关系，一个或者多个用户(例如一个公司)，但只有一个公司(一个)用户。在这种情况下，两表解决方案是正确的。

如果存在多对多关系(一个公司可以有多个用户，并且一个用户可以隶属于多个公司)，那么三表解决方案是正确的。

请注意，效率并不是这里真正的问题。数据的性质决定了应使用哪种解决方案。