宽高桌-每个人的优势

Question

我想为UserPreferences创建一个表。每个用户都有一组有限的用户首选项。因此，可以通过两种方式对此进行建模：

1. 一个宽表：UserPreferenceByUser（id int，userid int，preference1 int， preference2 int）
2. 一个高表：UserPreferenceByCode（id int，userid int，代码nvarchar（25），     值int）

速度因素并不重要，因为它们将在应用程序启动时被检索一次。

1的优缺点：

• 在客户端上，一个对象拥有所有首选项。 （更易于在客户端上使用）
• 但是，每次添加首选项时，都必须修改表并更新应用程序。
• 可以将默认首选项值放入默认值 领域。

2的优点/缺点：

• 在客户端上，数组保留首选项。 （更难使用）
• 如果添加了新的首选项，则无需更改数据模型。但是，添加新用户时，没有默认首选项。
• 如果未找到首选项，则必须添加一条新记录，以查找另一个表（DefaultUserPreferences）中的默认首选项值。

我在上面是否缺少任何优点或缺点？

在我看来，在理想的解决方案上看这是将数据存储为UserPreferenceByCode，然后返回一组透视数据，以便它在客户端上显示为UserPreferenceByUser。

Answer 1

您肯定缺少一些注意事项，并且有一些错误。

  

但是，添加新用户时，没有默认的首选项。

这是不正确的。默认首选项不像default约束那样简单，但是可以使用触发器，带有default表达式的case或更常见的“默认”用户来添加。实际上，这是一个优势，因为默认值可能会根据用户的其他特征（例如语言或角色）而有所不同。

您还缺少一些重要的注意事项：

• 宽表通常较小（因为不重复输入键），尤其是在首选项不稀疏的情况下。
• 狭窄的表格往往要求首选项都具有相同的类型。
• 窄表使您可以维护其他信息，例如更改首选项的日期。

最后两个注意事项-以及轻松添加新首选项的功能-在决定使用哪种方法时通常很重要。

在某些情况下，我使用了混合方法，其中初始首选项存储在列中，其他首选项存储在单独的表中，甚至存储在JSON / XML列中。