der*_*non 5 schema normalization
我是一名开发人员（学生），正在寻找一些关于在创建表以对具有许多可选字段的实体建模时应该遵循的最佳方法的建议。
需要对Organization具有几个关键字段（例如id和 ）的实体进行建模name。还有一个连接表 from UserstoOrganization指定谁属于Organization以及他们的角色是什么。
这个问题我有涉及许多属于可选字段Organization，如website，email和social links。以下是我目前处理这个问题的想法：
contact_information表，该表从查找表中organization_id引用contact_type_id（网站、电子邮件、Facebook 等），并具有value用于实际内容的通用字段。
我倾向于#2，因为它与我为物理地址所做的方法类似，但我不确定它是否是最好的解决方案，因为 DBA 不是我的强项。如果有我不知道的第三个甚至第四个选项，我也很想知道这些。
你的第二个选择更灵活，但我不确定你为什么担心“更多的桌子”。通常这将使用单个表完成：
联系类型 ------------- 身份证（PK） 姓名 联系方式 --------------- ID contact_type_id（FK 到 contact_types.id） 价值 组织_联系人 --------------------- 身份证（PK） contact_detail_id（FK 到 contact_details） 组织 ID（FK 到组织）
像这样填充：
联系类型 ------------- 身份证 | 姓名 ----+------------ 1 | 网址 2 | facebook_url 3 | 电话_1 联系方式 --------------- 身份证 | type_id | 价值 ----+------------+------- 1 | 1 | www.stuff.com 2 | 3 | (111) 111-1111 3 | 2 | facebook.com/?profileid=stuff 组织_联系人 --------------------- 身份证 | contact_detail_id | 组织 ID ---+--------------------+---------------- 1 | 1 | 1 2 | 2 | 1 3 | 3 | 1
此架构只有 3 个表（不是“吨”），您可以根据需要拥有任意数量的联系人类型。连接并没有那么复杂。您的contact_details表格会很大，因为每条联系信息有 1 条记录，但除非每个组织和“吨”或多个组织都有“大量”的联系信息，否则这可能不会成为太大的问题。;)
您还可以拥有一个contact_details存储所有字段的表。像这样的东西：
联系方式 --------------- 身份证（PK） main_email secondary_email 网址 facebook_url Linkedin_url myspace_url street_address_line_1 street_address_line_2 street_address_line_3 城市 prov_state 国家 邮政编码 电话号码1 电话号码2 传真号码
这种结构要简单得多，但更静态。如果您不打算非常更改您的联系人数据集，并且您认为大多数记录都会填写最多（或超过某个阈值）的字段，我怀疑这会表现得更好。