哪个数据库表Schema更有效?

时间:2008-09-02 04:01:10

标签: database-design

哪种数据库表架构更有效,为什么?

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

OR

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

鉴于用户和公司之间存在一对一的关系。

6 个答案:

答案 0 :(得分:7)

这是一个开放式问题,取决于您的业务规则。您拥有的第一个选项只允许一个公司映射到一个用户。你正在定义多对一的关系。

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

他们解决了不同的问题,并根据您要解决的问题确定应该使用的模式。

严格地说,从“交易”的角度来看,第一个架构会更快,因为您只需要为用户对象提交一行以与公司关联并检索您的用户工作的公司仅需要一个联接,但是如果您的业务需求发生变化,并且要求您让多个公司为用户提供帮助,那么第二个解决方案将会更好地扩展。

答案 1 :(得分:6)

可以肯定的是,鉴于该约束,较早的效率更高。要获得相同的信息,您的查询中的联接数量会减少。

答案 2 :(得分:1)

一如既往地取决于此。我个人会回答第一个答案,因为它会有更少的连接,并且更容易维护。较少的连接应该意味着它需要较少的表和索引扫描。

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

答案 3 :(得分:1)

这两个模式无法进行比较,因为它们具有不同的关系,您应该可以准确地查看表格的规范,然后找出适合所需关系的模式。

第一个意味着用户只能是一个公司的成员(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__;

您在select表上有一个额外的连接。如果你只想要belongs_to关系,那么第二个查询会比它应该做更多的工作 - 因此效率会降低。

答案 4 :(得分:0)

对于用户和公司而言,我认为你的意思是“多对一” - 除非你打算为每个用户建立一个独特的公司。

要回答您的问题,请使用第一种方法。少存储一个表可以减少空间并使查询使用更少的JOIN命令。此外,更重要的是,它正确匹配您所需的输入。数据库模式应描述所有有效数据的格式 - 如果它符合格式,则应视为有效。由于用户只能拥有一家公司,因此如果您使用第二个架构,则数据库中可能存在不正确的数据。

答案 5 :(得分:0)

如果用户和公司确实有一对一关系,那么您只需要一个表:

(ID, UserName, CompanyName)

但我怀疑你的确意味着用户和公司之间存在一对多关系 - 一个或多个用户公司,但只有一个公司用户。在这种情况下,双表解决方案是正确的。

如果存在多对多关系(公司可以拥有多个用户,并且用户可以连接到多家公司),那么三表解决方案是正确的。

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