database-design之使用用户定义字段的最佳数据库设计

在用户定义的表可以为实体指定不同类型的情况下，我有一个关于“最佳”设计解决方案的问题，但我想单独记录所有这些用户定义类型中的一种类型，因为这与另一个(用户定义的字段)表有关系。

例如，有员工。员工有 functions，由用户定义，但其中 1 个功能是 'mechanic'，我想保留 mechanic 的记录，因为 mechanics 有 skills基于productgroups，同样由用户定义，但除此之外，机械技能也可以由用户定义!

这是我的表格示例，让我解释下面的每个表格:

• 员工

员工是数据库中已知为内部员工的所有人员。

• 职能

功能是用户定义的记录，表示用户希望为员工添加的所有可能功能。 Mechanic 是一个预定义的功能记录，也是另一个表，可以保留它的额外记录。

• 员工_职能

员工和职能部门之间的连接表。

• Employee_MechanicSkills

设置为“机械师”功能的员工可以选择可用技能。这些技能涉及 CustomMechanicSkills 中自定义创建的技能，没有指向任何表格的链接以及 ProductGroups 定义的技能(见下文)。

• 产品组

ProductGroups 是用户定义的产品组。这些产品组需要由供应商或自己的公司提供服务和维护。如果是自己的公司，最好知道哪个员工具有能够为其执行维护所需的技能 - 因此 ProductGroups 和 Employee_MechanicSkills 之间的关系。还可以为机械师创建额外的 MechanicSkills。

• 自定义机械技能

用户定义的机械技能。用户可能不仅希望将机械技能与现有产品组相关联，而且还希望将产品组之外的其他自定义要求相关联。

• Employee_CustomMechanicSKills

Employees 和 CustomMechanicSkills 之间的连接表

我一直在想这个问题。在我的数据库设计中，数据完整性是关键，因此我尽量规范化。但另一方面，数据结构的不必要的复杂性也不是我想要的。

我想听听您对这种设计的优缺点的一些意见和不同看法，如果有的话，我可能会听到或看到更好、改进的设计。我非常感谢您的意见。

谢谢。

注意:命名约定尚未完全应用于此模型。

请您参考如下方法:

1. 从可靠的现有数据模型模式开始，以尽量减少对此的需求。

   https://dba.stackexchange.com/questions/12991/ready-to-use-database-models-example/23831#23831

   确保您了解表继承。

2. 考虑允许用户更改他们自己的数据库架构。例如，您可以淘汰一些用于数据结构的可重新加载的 Groovy、用于 DDL 迁移的 Hibernate 和 Roo HTML 生成并自动化这些。

3. 或者考虑带有索引的 XML 或 JSON 数据库列(可能在另一个表中)。 PostgreSQL 9.4 即将推出并且具有一些良好/快速的 JSON 处理能力。

   阅读:http://martinfowler.com/bliki/UserDefinedField.html

   还有这个http://www.slideshare.net/billkarwin/extensible-data-modeling

4. 除非万不得已，否则不要考虑使用 EAV。

仔细考虑您可能需要索引、搜索、排序、计数的字段，以及您需要什么样的数据完整性。