你如何决定使用nvarchar还是nchar?
例如,我注意到由sqlmembership提供程序创建的默认成员资格数据库将电子邮件列声明为nvarchar(256)类型。
对我来说,这似乎是电子邮件列的一个不必要的大最大值。我认为在正常情况下,长度超过40或50个字符的电子邮件应该很少见。
但是,由于诸如电子邮件地址之类的数据长度各异,它们是否应始终存储为nvarchar以消除冗余空间?
如果使用nvarchar作为电子邮件列。如果更改电子邮件地址,并且新电子邮件比先前的电子邮件长,是否会导致许多页面分割,从而产生性能成本?
您会考虑使用nchar(40)来代替电子邮件地址,以换取无页面分割性能成本而损失存储空间吗?
或者,使用nchar(40)会显着增加数据库大小,从而对查询速度造成其他性能影响吗?
“只有在知道要填充的列的数据大小时才使用nchar”是否是一个合理的遵循规则?
例如,我注意到由sqlmembership提供程序创建的默认成员资格数据库将电子邮件列声明为nvarchar(256)类型。
对我来说,这似乎是电子邮件列的一个不必要的大最大值。我认为在正常情况下,长度超过40或50个字符的电子邮件应该很少见。
但是,由于诸如电子邮件地址之类的数据长度各异,它们是否应始终存储为nvarchar以消除冗余空间?
如果使用nvarchar作为电子邮件列。如果更改电子邮件地址,并且新电子邮件比先前的电子邮件长,是否会导致许多页面分割,从而产生性能成本?
您会考虑使用nchar(40)来代替电子邮件地址,以换取无页面分割性能成本而损失存储空间吗?
或者,使用nchar(40)会显着增加数据库大小,从而对查询速度造成其他性能影响吗?
“只有在知道要填充的列的数据大小时才使用nchar”是否是一个合理的遵循规则?
USD
、GBP
等或美国州名缩写AZ
、ME
等)都可以使用定长的CHAR(x)
或NCHAR(x)
类型。对于超过此长度的任何内容,我总是选择可变长度字符串 - 如果你有一个VARCHAR(255)
并且大多数条目只有40-50个字符长,那么2字节的开销对于VARCHAR
类型非常值得。 - marc_s