1

一家公司受雇于另一家公司以在某个领域提供帮助。

所以我创建了以下表格： 公司：id、公司名称、公司地址 管理员：（与公司相关）id、company_id、用户名、电子邮件、密码、全名

然后，每个公司都有一些工人，我存储有关工人的数据。因此，工人有一个职业，签署的协议类型和其他一些常见的东西。

现在，每个公司的员工（协议类型、专业、其他常见事物）的父表和数据将是相同的。

我应该为每家公司创建 1 个新数据库吗？还是将所有数据存储到同一个数据库中？

谢谢。

4

2 回答 2

4

由于每个公司的“协议类型”、“职业”都相同，我建议有一个像“协议类型”这样的查找表，其中包含“ID”、“类型”等列，并参考“工人”中的“ID”列“ 桌子。我认为不需要新的数据库，关系数据库用于消除数据冗余并在实体之间创建适当的关系。

通过想象一家公司拥有一个数据库，最终每个数据库的“公司”表中都有一条记录。“管理员”和“工人”与该单条记录相关联。而其他常见的实体，如“AgreementTypes”将在其他表中。

因此，如果对协议类型有任何添加/修改，很难在所有数据库中都进行。类似地，如果有任何新实体要链接到“公司”实体，则再次基于这些实体属于 ONE 应用程序的假设重新访问所有数据库。

于 2012-12-18T23:14:11.153 回答
3

你应该有一个单一的数据库，其结构类似于这样（这有点过于简单，但你明白了）：

Companies
    CompanyID PK
    CompanyName
    CompanyAddress
    OtherCompanySpecificData

Workers
    WorkerID PK
    CompanyID FK
    LastName
    FirstName
    DOB
    AgreementTypeID FK
    ProfessionID FK
    UserID FK - A worker may need more than one user account
    Other UserSpecificData

Professions
    ProfessionID PK
    Profession
    OtherProfessionStuff

AgreementType
    AgreementTypeID PK
    AgreementTypeName
    Description
    OtherAgreementStuff

Users
    UserID PK -- A Worker may need more than 1 user account
    WorkerID FK
    UserName
    Password
    AccountStatus

Groups
    GroupID PK
    GroupName
    OtherGroupSpecificData

UserGroups --Composite Key with UserID and GroupID
    UserID PK 
    GroupID PK

显然，事情会变得更复杂一些，我不知道你的需求或商业模式。例如，如果公司可以有不同的部门，您可能希望创建一个 CompanyDepartment 表，然后能够将工人分配到各个部门。

等等。

您可以使数据结构更加原子化，随着数据库的增长，您的数据库将更加灵活。谷歌术语数据库规范化，特别是数据库的第三范式（3NF）（被认为是有效数据库设计的最小值）。

希望有帮助。如果您遇到困难，请随意详细说明 - 这里有很多关于 SO 的帮助。

于 2012-12-19T02:38:08.263 回答