关于数据库设计中varchar和int的选择

chaoup 2011-06-16 01:26:56
项目要求存储产品的24个左右的固定属性(均为整数和小数);
这些属性可能会被用到统计和更新;
这个表的总记录数在50W-100W条之间(设置有SQL作业定期清理废弃记录)。

目前,这24个属性我把他们全部放在一个nvarchar类型的列当中,用英文逗号隔开的,好处是添加或者更新的时候不用构造一大串的SLQ语句。。。。坏处是比如统计其中某个属性均值的时候只能循环记录来统计。
因为目前速度不够理想,我在想如果我将他们都单独做成24个int或numeric类型的列,会不会有改善呢?24个int列和一个nvarchar列谁占的空间会更大些呢?

补充道:表中在产品编号上有一个索引

请大家给些建议,任何方面的都行,谢谢!
...全文
984 13 打赏 收藏 转发到动态 举报
写回复
用AI写文章
13 条回复
切换为时间正序
请发表友善的回复…
发表回复
-晴天 2011-06-16
  • 打赏
  • 举报
回复 2
其实...
俺也是.....
半路出...呵呵,还没出家...
俺是学化学滴..吼吼.............
qq86619453 2011-06-16
  • 打赏
  • 举报
回复
学习了...
chaoup 2011-06-16
  • 打赏
  • 举报
回复
上来就看到这么多回复,感谢啊,2楼很给力!哈哈 本人半路出家没有啥基础也没看过啥书 都是边做边总结 今天又学习了,散分!
cd731107 2011-06-16
  • 打赏
  • 举报
回复
这24个属性我把他们全部放在一个nvarchar类型的列当中,用英文逗号隔开的,好处是添加或者更新的时候不用构造一大串的SLQ语句。。。。坏处是比如统计其中某个属性均值的时候只能循环记录来统计。
重点在上面,数据库最重要的就是查询功能,你这样设计,只考虑输入的方便,
对关键的查询制造的很大的障碍,有些本末倒置了
-晴天 2011-06-16
  • 打赏
  • 举报
回复
[Quote=引用 5 楼 cainlai 的回复:]
1L晴天老大在我的帖子里面的回复 我也看了,就是关于给每张图片建立标签关键字的 数据库设计,我也知道用专门的表来存这些标签是最好的做法,但是我总觉得量大了点啊,有的回复说我说的情况是理想情况下的量,但是我不觉得啊:
一个站有几十万用户 不算理想情况吧
然后这些用户都是搞标志设计的,那么他们上传以往的作品案例,每个人传个上百张几百张作品,也不算理想情况吧
然后给这些作品每张作品指定5-10个标……
[/Quote]
你在标签表中加编号,作为聚集索引,查询速度应该不是问题,存储容量也不应该是问题.反过来说,你不另加一个表,那你的标签不还是有那么多?还是要同样放到硬盘上去?不还是要占用空间?你还不知道每行有可能存放多少标签的组合,那,你的字段长度不是得要用最长的,那多长是最长,冗余是多少?
更关键的是,那一堆用逗号分开的东西,你要查,会把你头搞大,效率会很差很差!
其实,我们大家都学过数据基础理论,可是实际做的时候都是凭自己的想象,总觉得自己想的有道理,可是,你的这些符合基础理论么?如果不符合,你有你的理论么?如果没有,还是按人家说的来办,而不是盲目地跟着感觉走.
BetterMe 2011-06-16
  • 打赏
  • 举报
回复
字段里面没中文就不需要用VARCHAR,这效率相当低,非要用,可以考虑char;
纯数字在不超2亿的情况下可以用int,效率高很多,但你又说有小数,那就用decimal(numeric效率并不好);
int占4字节;
索引不一定就能提高很明显的效率,如果索引建在标识列上效率不会高;另外如果是聚集索引,你可以用执行计划看下,如果是聚集扫描,可以用优化顾问优化下,索引查看比索引扫描效率要高很多;
小金牛儿 2011-06-16
  • 打赏
  • 举报
回复
你这个明显是要拆分舒服的很多啊 ,不拆分处理上太麻烦了啊!
xyc880813 2011-06-16
  • 打赏
  • 举报
回复
从2楼学习了
CainLai 2011-06-16
  • 打赏
  • 举报
回复
1L晴天老大在我的帖子里面的回复 我也看了,就是关于给每张图片建立标签关键字的 数据库设计,我也知道用专门的表来存这些标签是最好的做法,但是我总觉得量大了点啊,有的回复说我说的情况是理想情况下的量,但是我不觉得啊:
一个站有几十万用户 不算理想情况吧
然后这些用户都是搞标志设计的,那么他们上传以往的作品案例,每个人传个上百张几百张作品,也不算理想情况吧
然后给这些作品每张作品指定5-10个标签关键字 也不算是理想情况吧
这样算下来 几十万 X 几百张 X 若干个标签 就至少已经是千万级了,而且还会陆续增加啊,标签这东西又不是能定期作废删除的东西
kingtiy 2011-06-16
  • 打赏
  • 举报
回复
第一范式(1NF):要求数据是原子级的,数据不可再分。
要是不清楚数据数设计,先看下三范式吧
你这么多数据在一个字段里面,明显处理效率会低下呢.
bala7229291 2011-06-16
  • 打赏
  • 举报
回复
我觉得楼主设计的时候思路不对啊
从你的说法,你的设计好与坏取决于修改的语句的长短,难道不是性能?
使用规范设计的好处,1楼已经讲了不少。如果平均算你每个属性3位数吧,你用的是nvarchar那么就得占用6字节,如果你用int 是4字节,如果用tinyint就1字节。
你考虑的语句长,最多就影响着编译时间,如果你重复执行同一条语句的话,sql的过程缓存里存储着你的查询计划,根本不用再编译,如果在你要查询的列上建立索引,那更是能节省时间,如果你是100万的记录,建立一列的索引还不建立带来的性能(等待时间)的提升是很明显的
叶子 2011-06-16
  • 打赏
  • 举报
回复
围观晴天大大的回复
-晴天 2011-06-16
  • 打赏
  • 举报
回复
数据库这么设计,MSSQL伤不起啊!!!
每个属性都应该作为一列来处理,否则对不同属性的处理要从一堆字串里把指定属性挑出来的话麻烦死你有木有!!!
如果某个属性值字串中间来个英文逗号你怎么处理!!!办法有木有!!!
占用空间大小根本没什么关系的,你总共才100W条记录,人家大一点的数据库上亿条记录有木有!!!
表的列多一些也不是什么问题,你总共才24列,人家大一点的数据库上百个列的有木有!!!
int 类型占用 4 字节,最大可达 2147483648,如果你用unicode字符串就得要 20 字节有木有!!!
如果你觉得你的数据没那么长,那用smallint,tinyint占用字节数更少有木有!!!
每个属性占用一列还可以创建索引,可以大大加快带属性值范围条件查找的速度有木有!!!
你数据库基础有木有!!!看过萨师煊的书有木有!!!有木有!!!

34,590

社区成员

发帖
与我相关
我的任务
社区描述
MS-SQL Server相关内容讨论专区
社区管理员
  • 基础类社区
  • 二月十六
  • 卖水果的net
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧