最早的设计想法是这样的：表A，图片信息：pic_id（主键，自增） user_id file_name file_size file_path upload_date
1 1001 tree.jpg 20 X:\XXX\1001\X 2011-06-11
2 1001 car.jpg 40 X:\XXX\1001\X 2011-06-11
3 1002 man.jpg 30 X:\xxx\1002\X 2011-06-11 表B，图片标签关联表：id（主键，自增） pic_id tag_id
1 1 1
2 1 2
3 1 3
4 1 4
5 1 5
6 2 6
7 2 7
8 2 8
9 2 9
10 2 10
11 2 11
12 3 12
13 3 13
14 3 14
15 3 15
16 3 16
17 3 17表C，标签信息：tag_id（主键，自增） tag_value
1 树
2 绿色
3 生命
4 自然
5 环保
6 汽车
7 银灰
8 流线
9 速度
10 奔驰
11 40万
12 男人
13 50岁
14 胡须
15 父亲
16 慈祥
17 医生然后又觉得这样设计太麻烦了，效率不够高，于是把表B和表C合并了，形成了新的表B：新表B，图片标签信息：tag_id（主键，自增） pic_id tag_value
1 1 树
2 1 绿色
3 1 生命
4 1 自然
5 1 环保
6 2 汽车
7 2 银灰
8 2 流线
9 2 速度
10 2 奔驰
11 2 40万
12 3 男人
13 3 50岁
14 3 胡须
15 3 父亲
16 3 慈祥
17 3 医生后来又觉得表B的行数到以后可能会很多，如果网站用户达到几十万，每个用户上传几十上百张图，那么这个表B的记录行数可能会很容易就上千万行了而且这些标签又不存在需要过期定期清理删除的问题，只会随时间的增长越来越多，那么上亿行我觉得都有可能这样的话，自增的主键感觉好像可能会不够用，如果换其他形式的主键，比如取精确到毫秒级别的日期+随机数形成nvarchar类型的文本来当主键，这样的话效率又肯定要低点而主键怎么设计还不是关键，主要的是我觉得行太多了有点可怕，好吧这种感觉就像一位大大说的一样，只是我稍微懂了点设计方面的原理以后，就想当然的冒出了这样一个顾虑，完全没有什么理论基础……或者说我太低估数据库的处理能力了？于是我尝试又把表A和表B合并，形成新的表A，把每张图片的若干个标签以英文逗号分隔，算成一张图片的一个整体属性：新表A，图片信息：pic_id（主键，自增） user_id file_name file_size file_path upload_date tag_value
1 1001 tree.jpg 20 X:\XXX\1001\X 2011-06-11 树,绿色,生命,自然,环保
2 1001 car.jpg 40 X:\XXX\1001\X 2011-06-11 汽车,银灰,流线,速度,奔驰,40万
3 1002 man.jpg 30 X:\xxx\1002\X 2011-06-11 男人,50岁,胡须,父亲,慈祥,医生这样设计主要考虑是：这些标签值在实际使用需求中不需要求和什么的，作用很单一就是用来对比用户搜索输入的关键字的：tag_value like '%关键字%'如果用户对一张图片定义的某个标签进行了修改，我也不需要在意他具体修改了哪个值，直接整体对所有标签覆盖更新就可以like搜索对索引支持不好，效率低的话，可以用全文索引（最近才从一位大大口中了解到的，我是初学者……）标签的个数和每个标签的字数我可以进行限制，比如一张图片最多5个标签或者10个标签，每个标签值最多7个汉字，那么tag_value字段设置成nvarchar(100)也足够了我这样设计，好像标签的感觉就弱化了？如果把一张图片比喻成一个人的话，那么tag_value字段更像是这个人的一个类似于简历或者自我描述的属性字段……标签在一般的网站应用中是否还有其他更多的功能，我把标签想成只是用于搜索关键字对比是不是想得太简单了？以上就是我自己的考虑，各位老大，能不能给我一个准确的说法，帮我决定下到底用哪种设计方法好？一下引用一些高人们给出的观点：你在标签表中加编号,作为聚集索引,查询速度应该不是问题,存储容量也不应该是问题.反过来说,你不另加一个表,那你的标签不还是有那么多?还是要同样放到硬盘上去?不还是要占用空间?你还不知道每行有可能存放多少标签的组合,那,你的字段长度不是得要用最长的,那多长是最长,冗余是多少?
更关键的是,那一堆用逗号分开的东西,你要查,会把你头搞大,效率会很差很差!
其实,我们大家都学过数据基础理论,可是实际做的时候都是凭自己的想象,总觉得自己想的有道理,可是,你的这些符合基础理论么?如果不符合,你有你的理论么?如果没有,还是按人家说的来办,而不是盲目地跟着感觉走.如果是要实现理论上的这种数据量的话 分表是一种办法 可以降低数据的数量级
例如标签表 多少个标签分多少张表 颜色表，行业表，主题内容表，制作软件表
或者你把一张作品的标签分类存成一个xml字段，一个作品对应标签表一条记录这样子
1 1001 tree.jpg 20 X:\XXX\1001\X 2011-06-11
2 1001 car.jpg 40 X:\XXX\1001\X 2011-06-11
3 1002 man.jpg 30 X:\xxx\1002\X 2011-06-11 表B，图片标签关联表：id（主键，自增） pic_id tag_id
1 1 1
2 1 2
3 1 3
4 1 4
5 1 5
6 2 6
7 2 7
8 2 8
9 2 9
10 2 10
11 2 11
12 3 12
13 3 13
14 3 14
15 3 15
16 3 16
17 3 17表C，标签信息：tag_id（主键，自增） tag_value
1 树
2 绿色
3 生命
4 自然
5 环保
6 汽车
7 银灰
8 流线
9 速度
10 奔驰
11 40万
12 男人
13 50岁
14 胡须
15 父亲
16 慈祥
17 医生然后又觉得这样设计太麻烦了，效率不够高，于是把表B和表C合并了，形成了新的表B：新表B，图片标签信息：tag_id（主键，自增） pic_id tag_value
1 1 树
2 1 绿色
3 1 生命
4 1 自然
5 1 环保
6 2 汽车
7 2 银灰
8 2 流线
9 2 速度
10 2 奔驰
11 2 40万
12 3 男人
13 3 50岁
14 3 胡须
15 3 父亲
16 3 慈祥
17 3 医生后来又觉得表B的行数到以后可能会很多，如果网站用户达到几十万，每个用户上传几十上百张图，那么这个表B的记录行数可能会很容易就上千万行了而且这些标签又不存在需要过期定期清理删除的问题，只会随时间的增长越来越多，那么上亿行我觉得都有可能这样的话，自增的主键感觉好像可能会不够用，如果换其他形式的主键，比如取精确到毫秒级别的日期+随机数形成nvarchar类型的文本来当主键，这样的话效率又肯定要低点而主键怎么设计还不是关键，主要的是我觉得行太多了有点可怕，好吧这种感觉就像一位大大说的一样，只是我稍微懂了点设计方面的原理以后，就想当然的冒出了这样一个顾虑，完全没有什么理论基础……或者说我太低估数据库的处理能力了？于是我尝试又把表A和表B合并，形成新的表A，把每张图片的若干个标签以英文逗号分隔，算成一张图片的一个整体属性：新表A，图片信息：pic_id（主键，自增） user_id file_name file_size file_path upload_date tag_value
1 1001 tree.jpg 20 X:\XXX\1001\X 2011-06-11 树,绿色,生命,自然,环保
2 1001 car.jpg 40 X:\XXX\1001\X 2011-06-11 汽车,银灰,流线,速度,奔驰,40万
3 1002 man.jpg 30 X:\xxx\1002\X 2011-06-11 男人,50岁,胡须,父亲,慈祥,医生这样设计主要考虑是：这些标签值在实际使用需求中不需要求和什么的，作用很单一就是用来对比用户搜索输入的关键字的：tag_value like '%关键字%'如果用户对一张图片定义的某个标签进行了修改，我也不需要在意他具体修改了哪个值，直接整体对所有标签覆盖更新就可以like搜索对索引支持不好，效率低的话，可以用全文索引（最近才从一位大大口中了解到的，我是初学者……）标签的个数和每个标签的字数我可以进行限制，比如一张图片最多5个标签或者10个标签，每个标签值最多7个汉字，那么tag_value字段设置成nvarchar(100)也足够了我这样设计，好像标签的感觉就弱化了？如果把一张图片比喻成一个人的话，那么tag_value字段更像是这个人的一个类似于简历或者自我描述的属性字段……标签在一般的网站应用中是否还有其他更多的功能，我把标签想成只是用于搜索关键字对比是不是想得太简单了？以上就是我自己的考虑，各位老大，能不能给我一个准确的说法，帮我决定下到底用哪种设计方法好？一下引用一些高人们给出的观点：你在标签表中加编号,作为聚集索引,查询速度应该不是问题,存储容量也不应该是问题.反过来说,你不另加一个表,那你的标签不还是有那么多?还是要同样放到硬盘上去?不还是要占用空间?你还不知道每行有可能存放多少标签的组合,那,你的字段长度不是得要用最长的,那多长是最长,冗余是多少?
更关键的是,那一堆用逗号分开的东西,你要查,会把你头搞大,效率会很差很差!
其实,我们大家都学过数据基础理论,可是实际做的时候都是凭自己的想象,总觉得自己想的有道理,可是,你的这些符合基础理论么?如果不符合,你有你的理论么?如果没有,还是按人家说的来办,而不是盲目地跟着感觉走.如果是要实现理论上的这种数据量的话 分表是一种办法 可以降低数据的数量级
例如标签表 多少个标签分多少张表 颜色表，行业表，主题内容表，制作软件表
或者你把一张作品的标签分类存成一个xml字段，一个作品对应标签表一条记录这样子
http://topic.csdn.net/u/20110616/01/3102ba81-81e8-45df-929c-cbef5b4faf1f.html
——中级都用不好全文索引所以还是不要出现like '%tag%'的需求标签的个数和每个标签的字数我可以进行限制，比如一张图片最多5个标签或者10个标签，每个标签值最多7个汉字，那么tag_value字段设置成nvarchar(100)也足够了
——如果这个可以限制，倒是无所谓了：建10个tag字段，只是搜的时候要搜10次——另外，tag们其实最好能树形。。呵呵，个人最喜欢树形
不用like '%tag%' 这样的语句话，那如果当用户搜索的关键字是“环保”的时候，如果一个图片的标签是“环保业”的话，那如果才能让这个图片被搜索出来呢？charindex？还是用其他什么方法？