求问，从数据库的角度来说，下面三种方法哪种更好一点
本帖最后由 kuangtuxue 于 2013-09-05 19:35:03 编辑 要存储长度大概为十几万的字符串（比如是用户信息），一个用户信息对应一个用户，然后一个用户信息里有一千多个用户信息类别（比如兴趣或者职业什么的），一个用户信息类别里的字符串最大不超过两千。
方法1：用一个nvarchar(4000)类型的列，然后以“性别,男,|兴趣,足球,篮球|......|”这种格式的字符串在后台进行判断，拆分成多个字符串用多个行来存放，大概四五十行能存完一个用户信息。
方法2：用一个nvarchar(50）类型的列存放用户信息类别（比如“兴趣”），再用一个nvarchar(2000）类型的列存放这个用户类别下的信息（比如“足球,篮球,”）。这样的话，一个用户信息得用一千多行才能存完（一个用户信息类别一行）。
方法3：直接用nvarchar(max)类型的列，然后以“性别,男,|兴趣,足球,篮球|......|”这种格式的字符串存放，不用拆分，一行就能存下。
用户信息的内容上的变更比较频繁，也就是update比较多，用户变更信息的时候，后台会对这个用户的用户信息进行判断，判断用户信息是否已经包含了某个用户信息分类，然后再根据这个进行变更。
方法1：后台的逻辑判断最复杂，首先得判断要更新的这个用户信息分类是否已经存在，然后得分割两次字符串（用“|”分隔符和“,”分割符）,接着还要判断数据变更后的长度会不会超出4000，超出了的话又得判断这个用户还有没有其他行有足够的长度来容纳更新数据，假如没有就得插入新行。
方法2:后台的逻辑判断最简单，只用分割一次字符串（用分割符“,”），不用判断会不会超出长度，对于用户信息类别是否已经存在，也非常容易，还不用判断字符串长度是否会超过上限。
方法3:后台逻辑判断复杂度在方法1和方法2之间，和方法1一样，也得分割两次字符串，也得判断用户信息列别是不是存在，但是不用判断会不会字符串长度是否会超过上限。
假如单纯从后台处理方便与否的角度来选，我肯定选方法2，比方法1和3容易多了。但是我对数据库不怎么了解，比如方法2，一个用户就得用一千多行是不是太多了点？还有方法3，用nvarchar(max)，数据量假如很大的情况下，会不会更新和查找的效率会变得很低？
所以，我想问下，从数据库执行效率和所占空间的角度来说，哪种方法好一点？
[解决办法]
方法1：用一个nvarchar(4000)类型的列，然后以“性别,男,
[解决办法]
兴趣,足球,篮球
[解决办法]
......
[解决办法]
”这种格式的字符串在后台进行判断，拆分成多个字符串用多个行来存放，大概四五十行能存完一个用户信息。
这个数据库是你设计的吗？为何象性别、兴趣这样都放到一直字符串里？为什么不单独一列出来，如果有很长的文本内容，可以考虑用ntext类型，而不是用nvarchar(4000)，就算是用nvarchar类型，也要这样nvarchar(max)
数据库设计问题，好好考虑。
[解决办法]
个人觉得采用方法二比较合适，你在考虑保存方便和节省空间的同时，更重要的是考虑可扩展性。方法二非常适合后续扩展。做数据库设计最重要的是要把实体及实体间的关系划分好。
[解决办法]
2005以上，用XML类型来存储比较好
[解决办法]
方法二吧，难道性别也是经常更新的么，从这个角度来来看，你可以分析一下要记录的用户信息分类，
可考虑把用户的自然属性信息（如性别、出生日期、民族...），这类信息是人人都有，并且有且仅有一条，这类信息固定存在一个表中；其它较易变动的，可能多条，另建表存储，如果信息量太大，可以考虑再次分类...
[解决办法]
粗略看了，方法2是优选，在RDBMS里，也是正道
------解决方案--------------------
建议3个表:
用户表: 用户ID, 用户名..
用户信息类别表: 类别ID, 类别名称..
用户信息表; 用户ID, 类别ID, 内容..
