联系人管理数据库设计建议
Suggestion for a contact management database design
我目前正在为一家商会设计联系人管理数据库。数据库的目标是存储所有person(除了我们自己的员工),所有记录companies(正规公司和商会会员) ,个人和公司的地址,员工当前负责的任务,我们员工的列表(用户) 和会议室内的角色。
商业规则
- 一个
person
一个 company
- 一个
company
有多个person
person
和 company
可以有多个 address
- 一个
company
可以是多个industry
- 一个
industry
可以有多个company
- 一个
company
可以有多个membertype
- 一个
membertype
可以有多个company
- 一个
user
可以玩多个role
- 一个
role
可以分配给多个user
- 一个
user
可以有多个task
- 一个
task
可以被多个user
处理
- 一个
task
可以定位多个person
- 一个
person
可以被多个task
定位
- 一个
person
只能加一个user
- 一个
user
可以加多个person
- 一个
company
可以有0个或1个parent_company
- 一个
parent_company
可以有多个child公司
我想出了以下设计,并进行了一些修改:
问题
- 是否有更好的方法来显示
user-task-person
关系?
- 例如,如果
person
只能有一个email
但可以有多个tel
,我是否应该为[=47=多做一个table ]而email
还在person
table?它会被认为是"unclean"吗?
- 对于table
membertype
,company_id
和typename
是否都应该PK?
- 这个模式现在看起来如何?还有一些规范化要做吗?
我是数据库新手,肯定存在一些设计上的缺陷或错误,希望大家能给我一些建议,让我改正和改进这个设计。谢谢^~^
我看到的主要问题是,虽然所有主键都定义为 Int,但一些外键或引用被定义为 varchar。
- 联系的公司table
- user_role 用户 table
- parent_company 在公司
- added_by 用户 table
此外,role_id 的长度为 10,而所有其他主键的长度均为 11。
就个人而言,我更喜欢大写的 table 名称、用户、公司等
编辑版本的更新:
您可能想为 phone、邮件、传真等创建一个 table,例如 contact_info
,它可以包含一个包含联系信息的字符串字段和一个类型字段(电子邮件、 phone、传真、...)。这样你可以存储多个 phone 号码,例如,如果你想将电子邮件限制为一个,你可以将它留在 person
table 中并且不允许它在这里或有业务规则在 contact_info
中只允许一个电子邮件行。
如果您想为 company
存储电子邮件或 phone 号码,例如 contact@somecompany.com 或公司总机号码
For the table membertype, should company_id and typename both be PK?
是
第二次更新
关于地址解决方案:
address
table 不应该包含足够的信息来使每个地址唯一,我可以理解一家公司可以有多个地址,但是否应该允许两家公司拥有相同的地址(通过那个我的意思是数据库中的同一行)所以也许它应该从 company
和“地址”改为一对多,但在另一个方向是一对一。
我还认为在两个地址中添加某种标签可能会很好-link tables 这样人们就可以轻松识别像 "home"、"work"、"Office", "Warehouse"...
我目前正在为一家商会设计联系人管理数据库。数据库的目标是存储所有person(除了我们自己的员工),所有记录companies(正规公司和商会会员) ,个人和公司的地址,员工当前负责的任务,我们员工的列表(用户) 和会议室内的角色。
商业规则
- 一个
person
一个company
- 一个
company
有多个person
person
和company
可以有多个address
- 一个
company
可以是多个industry
- 一个
industry
可以有多个company
- 一个
company
可以有多个membertype
- 一个
membertype
可以有多个company
- 一个
user
可以玩多个role
- 一个
role
可以分配给多个user
- 一个
user
可以有多个task
- 一个
task
可以被多个user
处理
- 一个
task
可以定位多个person
- 一个
person
可以被多个task
定位
- 一个
person
只能加一个user
- 一个
user
可以加多个person
- 一个
company
可以有0个或1个parent_company
- 一个
parent_company
可以有多个child公司
我想出了以下设计,并进行了一些修改:
问题
- 是否有更好的方法来显示
user-task-person
关系? - 例如,如果
person
只能有一个email
但可以有多个tel
,我是否应该为[=47=多做一个table ]而email
还在person
table?它会被认为是"unclean"吗? - 对于table
membertype
,company_id
和typename
是否都应该PK? - 这个模式现在看起来如何?还有一些规范化要做吗?
我是数据库新手,肯定存在一些设计上的缺陷或错误,希望大家能给我一些建议,让我改正和改进这个设计。谢谢^~^
我看到的主要问题是,虽然所有主键都定义为 Int,但一些外键或引用被定义为 varchar。
- 联系的公司table
- user_role 用户 table
- parent_company 在公司
- added_by 用户 table
此外,role_id 的长度为 10,而所有其他主键的长度均为 11。
就个人而言,我更喜欢大写的 table 名称、用户、公司等
编辑版本的更新:
您可能想为 phone、邮件、传真等创建一个 table,例如 contact_info
,它可以包含一个包含联系信息的字符串字段和一个类型字段(电子邮件、 phone、传真、...)。这样你可以存储多个 phone 号码,例如,如果你想将电子邮件限制为一个,你可以将它留在 person
table 中并且不允许它在这里或有业务规则在 contact_info
中只允许一个电子邮件行。
如果您想为 company
存储电子邮件或 phone 号码,例如 contact@somecompany.com 或公司总机号码
For the table membertype, should company_id and typename both be PK?
是
第二次更新
关于地址解决方案:
address
table 不应该包含足够的信息来使每个地址唯一,我可以理解一家公司可以有多个地址,但是否应该允许两家公司拥有相同的地址(通过那个我的意思是数据库中的同一行)所以也许它应该从 company
和“地址”改为一对多,但在另一个方向是一对一。
我还认为在两个地址中添加某种标签可能会很好-link tables 这样人们就可以轻松识别像 "home"、"work"、"Office", "Warehouse"...