规范化数据库中的非规范化表设计？

Question

上周，开发人员和 DBA 就开发人员在我们的 OLTP 环境中创建的具有 400 多个列以及 VARCHAR、日期时间和浮点数组合的一组表进行了讨论。当被问及这种非规范化表的原因时，我们被告知供应商是如何提供记录记录集的，因此映射表必须以这种方法设计。此外，表将用于跨其他规范化表的交叉连接，并且表可能会增长到更大的大小。目前，几乎没有表（375 列）具有类似的设计，并且同一数据库中的平均行数为 300 万或更多。这些现有的非规范化表按日期分区。这些现有表没有性能问题，因为它们还没有被大量使用。

问题：

1. 除了说这是一个糟糕的设计之外，您是否看到这种设计有任何明显的问题可以说服开发人员在规范化环境中重新考虑他们的设计策略。当然，归一化与非归一化各有优缺点。
2. 根据您的经验，您是否看到过此类列式表的任何常见实时性能问题，例如锁定、DML 等需要更长的时间？开发人员甚至提到如果 SQL Server 出现任何性能问题，可以考虑将 MongoDB 作为他们的替代方案。
3. 如果在 OLTP 中更频繁地设计此类表，您是否有一些可能发生的高级性能问题。请注意，如果需要解决任何 IO 或 CPU 问题，该公司可以灵活地添加 CPU 或内存。

我知道在 SQL 2012 中，有列存储索引，但尚未探索。

Answer 1

需要提出的一些问题：

• 对于 OLTP，在那么宽的表中插入会非常慢

• 重复冗余信息会浪费大量空间

• 列存储是不可修改的索引类型，因此您不能在 OLTP 环境中使用它

• 您以这种方式极大地复杂化了参照完整性控制。您不能仅仅通过创建外键来确保获得字段的有效值。

• 索引将是一场噩梦

这里真正的问题是开发人员不了解设计。

将客户端数据保持在其本机格式很好。我做这种事情是为了谋生，我总是得到有 500 多个字段的表。处理它的方法是将您的RAW数据与您的BUILT数据分开。

如果客户端给了你一个超宽的表，你需要自己规范化它来制作一个可用的数据集。没有什么能阻止您创建一个将数据分解到适当表中的过程。