Dej*_*jan 7 database-design sql-server azure-sql-database slowly-changing-dimension
我正在设计一个包含很多行的表。所以需要注意不要存储太多信息。其中一列是 NVARCHAR(MAX) 列,它包含我们客户的地址。由于地址不经常更改,此列将包含许多重复值,因此包含相当多的冗余。
所以我想知道我是否需要通过维护某种查找表来解决字符串来规范化(请注意,如果地址发生变化,我需要维护历史记录 - 所以这不是通常的规范化问题),或者如果 SQL Server指向幕后字符串的相同引用。或者它可能提供了一个列选项来这样做。我想到的另一种方法是使用 COMPRESS,但我想这没有意义,因为数据本身(即地址)不长。
读/写性能不是那么重要,因为数据会随着时间的推移而累积。
Sol*_*zky 11
在“正常”条件下,没有,在数据VARCHAR和NVARCHAR列不是去欺骗(虽然在一个单一的重复的属性和/或元素名称XML值被减小到一个唯一的实例)。
使用数据压缩选项之一可能是您最好的选择。这里有一些要考虑的事情:
NVARCHAR(1 - 4000),不适NVARCHAR(MAX)用于(请投票支持/支持:Unicode 压缩 NVARCHAR(MAX))。NVARCHAR(MAX),但仅适用于行内数据。行外数据(LOB 页)不被压缩。由于数据不会真正发生变化,您应该查看列存储索引选项(也可在 Azure SQL 数据库中使用):
列存储压缩应该比页面压缩更好。
此外,您可能应该避免使用该SPARSE选项,因为:
SPARSE与数据压缩相比,该选项没有任何好处。INT,DATETIME)。因此,在数据压缩可用之前,它对CHARand很有用NCHAR,但不适用于VARCHARorNVARCHAR因为它们在NULL.NULL。NULL通过向每个字节添加 2 个字节,它会略微损害非值。NULL50% - 60% 的行,以便获得足够的节省,值得使用此选项。有关使用字符数据的更多详细信息,请参阅我的以下帖子:
是重复的数据作为副本存储在 SQL Server 中
要更改此行为,您需要实现 PAGE COMPRESSION 功能 - 使用 ( data_compression = page) 选项创建或重建索引
这是一个很棒的功能,有助于节省空间。启用它后,SQL Server 会在幕后指向同一页面上的相同字符串引用
请注意 PAGE COMPRESSION 并非在每个 SQL Server 版本中都可用,它可能会产生一些 CPU 开销
因此,如果您的版本不允许页面压缩,您可能需要制作一个查找表
压缩很好,在您的情况下可能很有用,但无论如何您都应该规范化您的表,并尝试实现一种仅存储同一地址的一个副本的结构。这将减少冗余,并减轻您当前询问的主表。
另外需要考虑的两件事是:
NVARCHAR 可以使用两倍于同等使用长度的 VARCHAR 的空间(Solomon Rutzky 的回答链接了一篇关于此的好文章),因此它可以包含更多数据。如果您可以改用 VARCHAR,您可能可以将长度降低到对地址字段更合理的值,并节省更多空间。这是一篇比较两者的文章:SQL varchar 数据类型深入探讨
您还应该研究稀疏列,如果使用得当,它也可以为您节省大量空间。这是 Microsoft 文档:使用稀疏列
(重要的是要注意,对于值得研究的稀疏列,需要存在最少数量的 NULL 值。)
| 归档时间: |
|
| 查看次数: |
967 次 |
| 最近记录: |