使用灵活的用户配置文件设计数据库

Question

我正在设计一个可以为用户提供灵活属性的设计，我很困惑如何继续设计架构。

我制作了一张表，我保存了系统所需的信息：

表名：用户

• ID
• 用户名
• 密码

现在，我希望创建一个配置文件表，并且具有一对一的关系，其中配置文件表中的所有其他属性，例如电子邮件，名字，姓氏等。我的问题是：有没有办法添加第三个配置文件灵活的表格？换句话说，如果我的客户需要创建新属性，他/她将不需要对代码进行任何自定义。

Answer 1

您正在寻找规范化的表格。这是一个包含user_id，key，value列的表，这些列在User＆amp;之间产生1：N的关系。这个新表。查看http://en.wikipedia.org/wiki/Database_normalization以获取更多信息。规范化表格的性能并不令人惊讶，它可能需要一些有趣的规划来优化您的代码，但这是一个非常标准的做法。

Answer 2

将配置文件的固定部分保存在标准表中，以便于查询，添加约束等。

对于可配置的部分，听起来您正在寻找entity-attribute-value模型。额外的可配置性成本很高：所有内容都必须存储为字符串，您必须在应用程序中进行任何数据验证，而不是在数据库中。

Answer 3

如何使用这些属性？它们只是一个数据包还是用户希望系统能够对这些值做些什么？是否会有任何针对他们的报道？

如果系统必须对这些属性执行某些操作，那么您应该将它们设为列，因为无论如何都必须编写代码，这些代码会对值执行特殊操作。但是，如果客户只是希望他们存储数据，则EAV可能是票据。

如果您要实施EAV，我建议您在属性表中添加DataType列。这使您可以对输入的数据进行一些基本验证，并动态更改用于输入的控件。

如果您要使用EAV，那么您必须遵循的一条规则是从不编写您指定特定属性的任何代码。如果这些自定义属性只不过是一大堆数据，那么系统的这一部分的EAV将起作用。您甚至可以考虑创建一个XML列来存储这些属性。 SQL Server实际上具有XML数据类型，但所有数据库都具有某种形式的大型文本数据类型，这些类型也可以使用。在报告中，数据只会吐出来。您永远不会在报表上的特定位置放置特定值，也不会对数据执行任何类型的数值运算。

EAV的价格是守夜和纪律。无论您从管理层获得多大压力，您都必须在自己和其他开发人员之间遵守纪律，尤其是报告作者从不过滤特定属性。客户端想要过滤或对特定属性执行操作的那一刻，它必须成为列的第一类属性。如果您觉得无法维持这种规则，那么我只需为每个属性创建列，这意味着对代码进行调整，但这样可以减少混乱。