项目要求存储产品的24个左右的固定属性(均为整数和小数)；
这些属性可能会被用到统计和更新；
这个表的总记录数在50W-100W条之间（设置有SQL作业定期清理废弃记录）。目前，这24个属性我把他们全部放在一个nvarchar类型的列当中，用英文逗号隔开的，好处是添加或者更新的时候不用构造一大串的SLQ语句。坏处是比如统计其中某个属性均值的时候只能循环记录来统计。
因为目前速度不够理想，我在想如果我将他们都单独做成24个int或numeric类型的列，会不会有改善呢？24个int列和一个nvarchar列谁占的空间会更大些呢？补充道：表中在产品编号上有一个索引请大家给些建议，任何方面的都行，谢谢！
这些属性可能会被用到统计和更新；
这个表的总记录数在50W-100W条之间（设置有SQL作业定期清理废弃记录）。目前，这24个属性我把他们全部放在一个nvarchar类型的列当中，用英文逗号隔开的，好处是添加或者更新的时候不用构造一大串的SLQ语句。坏处是比如统计其中某个属性均值的时候只能循环记录来统计。
因为目前速度不够理想，我在想如果我将他们都单独做成24个int或numeric类型的列，会不会有改善呢？24个int列和一个nvarchar列谁占的空间会更大些呢？补充道：表中在产品编号上有一个索引请大家给些建议，任何方面的都行，谢谢！
每个属性都应该作为一列来处理,否则对不同属性的处理要从一堆字串里把指定属性挑出来的话麻烦死你有木有!!!
如果某个属性值字串中间来个英文逗号你怎么处理!!!办法有木有!!!
占用空间大小根本没什么关系的,你总共才100W条记录,人家大一点的数据库上亿条记录有木有!!!
表的列多一些也不是什么问题,你总共才24列,人家大一点的数据库上百个列的有木有!!!
int 类型占用 4 字节,最大可达 2147483648,如果你用unicode字符串就得要 20 字节有木有!!!
如果你觉得你的数据没那么长,那用smallint,tinyint占用字节数更少有木有!!!
每个属性占用一列还可以创建索引,可以大大加快带属性值范围条件查找的速度有木有!!!
你数据库基础有木有!!!看过萨师煊的书有木有!!!有木有!!!
从你的说法，你的设计好与坏取决于修改的语句的长短，难道不是性能？
使用规范设计的好处，1楼已经讲了不少。如果平均算你每个属性3位数吧，你用的是nvarchar那么就得占用6字节，如果你用int 是4字节，如果用tinyint就1字节。
你考虑的语句长，最多就影响着编译时间，如果你重复执行同一条语句的话，sql的过程缓存里存储着你的查询计划，根本不用再编译，如果在你要查询的列上建立索引，那更是能节省时间，如果你是100万的记录，建立一列的索引还不建立带来的性能（等待时间）的提升是很明显的
一个站有几十万用户 不算理想情况吧
然后这些用户都是搞标志设计的，那么他们上传以往的作品案例，每个人传个上百张几百张作品，也不算理想情况吧
然后给这些作品每张作品指定5-10个标签关键字 也不算是理想情况吧
这样算下来 几十万 X 几百张 X 若干个标签 就至少已经是千万级了，而且还会陆续增加啊，标签这东西又不是能定期作废删除的东西
纯数字在不超2亿的情况下可以用int,效率高很多,但你又说有小数,那就用decimal(numeric效率并不好);
int占4字节;
索引不一定就能提高很明显的效率,如果索引建在标识列上效率不会高;另外如果是聚集索引,你可以用执行计划看下,如果是聚集扫描,可以用优化顾问优化下,索引查看比索引扫描效率要高很多;
重点在上面，数据库最重要的就是查询功能，你这样设计，只考虑输入的方便，
对关键的查询制造的很大的障碍，有些本末倒置了