我在最近不得不使用的数据库中碰到了很多VARCHAR(1)字段.我翻了个白眼:显然设计师没有任何线索.但也许我是那个需要学习的人.有没有可能的理由使用VARCHAR(1)数据类型而不是CHAR(1)?我认为RDMS会自动将一个转换为另一个.
该数据库是MS SQL 2K5,但在当天从Access演变而来.
Ric*_*iwi 16
是的,它有意义.
它更容易在语言中定义.定义varchar以允许1-8000是一致且容易的,而不是说它需要2+或3+到8000.
VARCHAR(1)的VARying CHARacter方面就是这样.它可能不是最佳的存储,但传达了一个特定的含义,即数据是1个字符(课堂代码)或空白(外部活动)而不是NULL(未知/尚未分类).
存储在这方面起着很小的作用 - 查看CHAR(1)的数据库模式,您几乎可以预期它必须始终具有1个char值,例如信用卡必须具有16个数字.对于某些数据而言,情况根本不是这样,它可以是一个数据,也可以是非数据.
对于那些说三态[1-char |]的人来说,使用VARCHAR(1)和CHAR(1)+ NULL组合也存在差异.0-char | NULL]完全没用.它允许SQL语句,如:
select activity + '-' + classroom
from ...
Run Code Online (Sandbox Code Playgroud)
如果你使用char(1)+ NULL,否则会更加困难,这可以传达相同的信息,但有细微的差别.
Mit*_*eat 11
AFAIK,不.
一个VARCHAR(1)需要3个字节的存储(存储大小是数据的输入+ 2个字节的实际长度.参考文献.
a CHAR(1)需要1个字节.
从存储角度来看:根据经验,如果它小于或等于5个字符,请考虑使用固定长度的char列.
避免varchar(1)的原因(除了他们传达不良设计推理的事实,IMO)是使用Linq2SQL:LINQ to SQL和varchar(1)字段
A varchar(1)可以存储零长度("空")字符串.一个char(1)不能,因为它将填补到一个空间.如果这种区别对你很重要,你可能会赞成varchar.
除此之外,如果设计者想要允许将来可能需要更多字符的可能性,则可以使用一个用例.
从改变一个固定长度的数据类型char(1)来char(2)表示所有的表中的行需要被更新和任何索引或访问此列丢弃第一约束.
对生产中的大型表进行这些更改可能是非常耗时的操作,需要停机时间.
从更改列varchar(1)到varchar(2)是因为它是一个元数据只改变(即引用该列将需要删除和重建FK约束,但是没有必要重建索引或更新数据页)更加容易.
此外,每行节省2个字节可能并不总是实现.如果行定义已经很长,那么这并不总是会影响数据页面上可以容纳的行数.另一种情况是,如果在企业版中使用压缩功能,则存储数据的方式与Mitch在任何情况下的答案中提到的完全不同.双方varchar(1)并char(1)最终将存储在短期数据区域相同的方式.
@Thomas - 例如尝试这个表定义.
CREATE TABLE T2
(
Code VARCHAR(1),
Foo datetime2,
Bar int,
Filler CHAR(4000),
PRIMARY KEY CLUSTERED (Code, Foo, Bar)
)
INSERT INTO T2
SELECT TOP 100000 'A',
GETDATE(),
ROW_NUMBER() OVER (ORDER BY (SELECT 0)),
NULL
FROM master..spt_values v1, master..spt_values v2
CREATE NONCLUSTERED INDEX IX_T2_Foo ON T2(Foo) INCLUDE (Filler);
CREATE NONCLUSTERED INDEX IX_T2_Bar ON T2(Bar) INCLUDE (Filler);
Run Code Online (Sandbox Code Playgroud)
对于varchar它是微不足道的列定义从改变varchar(1)到varchar(2).这是仅元数据更改.
ALTER TABLE T2 ALTER COLUMN Code VARCHAR(2) NOT NULL
Run Code Online (Sandbox Code Playgroud)
如果变化是从char(1)到char(2)下面的步骤必须发生.
Code现在存储为char(2).| 归档时间: |
|
| 查看次数: |
7340 次 |
| 最近记录: |