我有一个场景，我让用户将他们的自定义首选项上传到我们的实用程序正在完成的转换中。所以，我们面临的问题是
我们是否应该将这些自定义映射保存在一个带有额外的 UID 或 GUID 列的表中 ,
或
我们是否应该为每个在我们这里注册的用户即时创建表格，并为他们的自定义映射完全提供一个单独的表格？
我们更倾向于只为自定义映射提供一个额外的列和一个表，但是这一列中的冗余数据对性能有影响吗？另一方面，逻辑要求我们规范化我们的表格并拥有单独的表格。我很困惑该怎么做。
【问题讨论】：
标签： sql-server sql-server-2008 database-design
通常的做法是使用带有用户 ID 的单个表。如果有经常重用的首选项，您可以将它们重构到一个单独的表中并一次性引用它们，但这取决于您。
为什么为每个用户创建一个表是个坏主意？好吧，如果您最终有 100 万用户，我认为您不希望数据库中有 100 万张表。这样做还可以保证您的查询充其量只是笨拙，通常比应有的速度慢，并且通常是动态生成的，EXECed - 通常是最后的选择，不一定安全。
【讨论】：
我继承了一个系统，在该系统中，最初的开发人员选择了每个客户端一个表的方法。我们现在正在重写系统！从开发人员的角度来看，您最终会遇到一团乱麻的动态 SQL 和循环。 DBA 会不高兴，因为他们每天早上醒来都会看到一个完全不同的数据库，这使得性能调优和维护变得不可能。
您可以在用户表中添加一个额外的 BLOB 或 XML 列，用于存储首选项。这称为属性包方法，但我也不建议这样做，因为它在许多情况下会影响查询性能。
在这种情况下，最好的方法是通过规范化来解决问题。一个单独的属性表，通过 PK/FK 关系连接到 users 表。我不建议使用 GUID。此 GUIiD 可能最终会成为 PK，这意味着您将拥有一个 16 字节的聚集索引，并且这也将传递到表上的所有非聚集索引。您可能还会在 Users 表中为此构建一个非集群索引。此外，您可能会陷入使用NEW_ID() 而不是NEW_SEQUENTIALID() 生成这些GUID 的陷阱，这将导致大量碎片。
如果您采用规范化方法并且担心以表格格式返回两个表中的结果，那么您可以简单地使用PIVOT 运算符。
【讨论】：