DBA*_*ser 6 performance database-design
上周,开发人员和 DBA 就开发人员在我们的 OLTP 环境中创建的具有 400 多个列以及 VARCHAR、日期时间和浮点数组合的一组表进行了讨论。当被问及这种非规范化表的原因时,我们被告知供应商是如何提供记录记录集的,因此映射表必须以这种方法设计。此外,表将用于跨其他规范化表的交叉连接,并且表可能会增长到更大的大小。目前,几乎没有表(375 列)具有类似的设计,并且同一数据库中的平均行数为 300 万或更多。这些现有的非规范化表按日期分区。这些现有表没有性能问题,因为它们还没有被大量使用。
问题:
我知道在 SQL 2012 中,有列存储索引,但尚未探索。
需要提出的一些问题:
对于 OLTP,在那么宽的表中插入会非常慢
重复冗余信息会浪费大量空间
列存储是不可修改的索引类型,因此您不能在 OLTP 环境中使用它
您以这种方式极大地复杂化了参照完整性控制。您不能仅仅通过创建外键来确保获得字段的有效值。
索引将是一场噩梦
这里真正的问题是开发人员不了解设计。
将客户端数据保持在其本机格式很好。我做这种事情是为了谋生,我总是得到有 500 多个字段的表。处理它的方法是将您的RAW
数据与您的BUILT
数据分开。
如果客户端给了你一个超宽的表,你需要自己规范化它来制作一个可用的数据集。没有什么能阻止您创建一个将数据分解到适当表中的过程。