在关系数据库(SQLServer)中将枚举值存储为字符串有什么含义
Mik*_*liy 2 sql-server data-modeling relational-database
因此,我需要使用状态字段设计产品生命周期的数据模型.状态可以说是:生产,服务,保修等.
经典方式只是具有单独的表状态,以及状态的外键.但是我想在这个专栏中只有字符串值.我理解的含义是:
- 缺乏价值验证 - 在我的情况下这是可以的,因为应用程序代码控制着这个值.
- 可能更多的存储 - 不确定这是否正确.SQL Server是否有一些优化？
- 索引 - 这里不确定.有什么问题吗？
- 表现 - 这里不确定.是否存在巨大的性能差异？
主要好处是:
- 可读/语义 - 无论表中的哪些数据都可以立即读取.
- 更容易使用 - 为枚举添加新值只是在应用程序级别添加枚举.无需在ORM中进行繁琐的配置.
我错过了什么吗？我概述的含义是否真实？你的建议？
我想有一定数量的Status值,因此可以使用CHECK约束在DB中进行验证.外键约束几乎完全相同,但使用引用表中的值并锁定它们.
ALTER TABLE产品添加约束CH_PRODUCTS_STATUS CHECK(状态='生产'或状态='服务')GO
是.无论如何还要存储更多 Int值将占用4个字节,而文本值"Services"将在varchar数据类型中占用8个字节,在nvarchar中占用16个字节.企业版中有一个页面压缩选项(自SQL Server 2016 SP1以来也是标准版)https://msdn.microsoft.com/en-us/library/cc280464.aspx,如你所见,据我所知压缩算法,int和varchar/nvarchar压缩之间的差异将是标题大小,因此如果Status值有一个小的有限选项,压缩将给你非常相同的结果.我创建了两个表(聚簇索引),它们具有相同的结构,但具有Status列的不同类型,并在每个表中插入100K行.
CREATE TABLE Products(Id int IDENTITY PRIMARY KEY,Product varchar(200)NOT NULL,Status varchar(50)NOT NULL,Date datetime NOT NULL)GO
CREATE TABLE Products2(Id int IDENTITY PRIMARY KEY,Product varchar(200)NOT NULL,Status int NOT NULL,Date datetime NOT NULL)GO
插入产品价值('5656','服务',GETDATE())GO 100000
INSERT INTO Products2 VALUES('5656',1,GETDATE())GO 100000
以下是他们的一些统计数据:
产品表格大小:543页(4.2 MB)产品2工作台面积:482页(3.7 MB)压缩产品(页面压缩)工作台面积:173页产品2压缩(页面压缩)工作台面积:173 pages
注意:本演示中使用的varchar数据类型,nvarchar将需要比varchar多两倍的容量.
与前一个问题中的大小相同.以下是索引创建的脚本:
CREATE INDEX IX_PRODUCTS_STATUS ON产品(状态)GO
创建索引IX_PRODUCTS2_STATUS ON Products2(状态)GO
产品索引规格:260页产品2索引规格:174页(3.7 MB)产品索引(页面压缩)表面大小:93页产品2索引(页面压缩)表面大小:93页
- 这是主要的考虑因素,为什么我已经用很多细节描述了前两点.在同一个表中存储字符串需要更多资源:
- 磁盘空间
- 用于从磁盘读取数据的处理器时间和磁盘IO
- 用于读取和缓存数据的RAM
可用RAM可以很好地指示在Products表中存储状态或将其移动到Statuses表,因为从RAM读取仍然比从磁盘读取要快得多.可以使用状态列的值的长度来计算大小差异.如果大小差异很大且SQL Server无法在RAM中保存活动数据,他将从磁盘读取数据并从RAM中清除其他可能很重要的数据.在这种情况下,将状态值移动到单独的表或启用压缩(如果此选项可用)是有意义的.
但与此同时,如果您将拥有单独的Statuses表,那么从Products to Statuses表创建外键可能是有意义的.在这种情况下,通过查找Statuses表,数据修改操作会稍微缓慢.此外,您将有+1连接,并且物理连接操作的CPU开销很小(通常会忽略cabe).