一个表中包含冗余数据的表与多个表

Question

我有一个场景，我让用户将他们的自定义偏好设置上传到我们的实用程序完成的转换。所以，我们面临的问题是

  

我们应该将这些自定义映射保留在一个表中，其中包含一个额外的UID列或GUID   ，

或

  

我们是否应该为每个注册我们的用户动态创建表格，并为他/她提供一个单独的自定义映射表格？

我们更倾向于只为自定义映射添加一个额外的列和一个表，但是这一列中的冗余数据是否会对性能产生影响？另一方面，逻辑要求我们规范化表并具有单独的表。我对于该做什么感到困惑。

Answer 1

通常的做法是使用具有用户ID的单个表。如果存在通常重用的首选项，您可以将它们重构为一个单独的表并一次性引用它们，但这取决于您。

为什么每个用户创建一个表是个坏主意？好吧，如果您最终拥有一百万用户，我认为您不希望数据库中有一百万个表。这样做也可以保证您的查询充其量只是笨拙，通常比它们应该更慢，而且通常是动态生成的EXEC - 通常是最后的选择而且不一定安全。

Answer 2

我继承了一个系统，原始开发人员选择使用每个客户端方法的一个表。我们现在正在重写系统！从开发的角度来看，最终会出现乱七八糟的动态SQL和循环。 DBA不会高兴，因为他们每天早上都会醒来到一个完全不同的数据库，这使得无法进行性能调整和维护。

您可以在users表中添加其他BLOB或XML列，以存储首选项。这称为属性包方法，但我也不建议这样做，因为它会在许多情况下妨碍查询性能。

此方案中的最佳方法是通过规范化解决问题。属性的单独表，以PK / FK关系连接到users表。我不建议使用GUID。这个GUiD很可能最终成为PK，这意味着你将拥有一个16字节的聚簇索引，并且还将传递给表上的所有非聚簇索引。您可能还会在Users表中为此构建非群集索引。此外，您可能会冒着使用NEW_ID()而非NEW_SEQUENTIALID()生成这些GUID的陷阱的风险，这将导致大量碎片。

如果采用规范化方法，并且您担心以表格格式在两个表格中返回结果，那么您只需使用PIVOT运算符。