7,714
社区成员
发帖
与我相关
我的任务
分享关系数据库如何完美的实现多值字段
在设计数据库中经常遇到需要多值字段的场合，就拿用户资料里的“兴趣爱好”为例说明吧
也许有的人只有一项兴趣爱好，也许有的人会有100项兴趣爱好，但是你要精确的检索它
尝试一：搞几个“兴趣爱好1”“兴趣爱好2”“兴趣爱好3”字段在用户资料表里面，多出来的就让它空着。实际上有些通讯录软件正是这样做的
困难：预留的字段毕竟还是有上限的，况且在绝大部分人只有1项的情况下，浪费了数据库
尝试二：另外建一个表Relation([intUserID],[intFavourateID])，从这里面查Where intUserID=***。实际上大部分新闻系统的无限级分类就是这样实现的
困难：要是多值字段有好几个，数据库的结构会被弄得一塌糊涂，乱七八糟
尝试三：仅一个字段,数据类似“1,5,7,3,92”这样
困难：这个几乎是最完美的方案，但是检索起来将会十分困难，比如你要检索有“3”的，如果检索“3”，就会把“93”“123”都检索进去了，如果检索“,3”“3,”“,3,”就会没检索到仅仅有“3”的条目。但是如果都改成“,1,5,7,3,92”和“,3,”，因为绝大部分人只有1项，所以也会浪费很多数据库资源
请问有没有人给出终极完美解决方案呢？
也许有的人只有一项兴趣爱好，也许有的人会有100项兴趣爱好，但是你要精确的检索它
尝试一：搞几个“兴趣爱好1”“兴趣爱好2”“兴趣爱好3”字段在用户资料表里面，多出来的就让它空着。实际上有些通讯录软件正是这样做的
困难：预留的字段毕竟还是有上限的，况且在绝大部分人只有1项的情况下，浪费了数据库
尝试二：另外建一个表Relation([intUserID],[intFavourateID])，从这里面查Where intUserID=***。实际上大部分新闻系统的无限级分类就是这样实现的
困难：要是多值字段有好几个，数据库的结构会被弄得一塌糊涂，乱七八糟
尝试三：仅一个字段,数据类似“1,5,7,3,92”这样
困难：这个几乎是最完美的方案，但是检索起来将会十分困难，比如你要检索有“3”的，如果检索“3”，就会把“93”“123”都检索进去了，如果检索“,3”“3,”“,3,”就会没检索到仅仅有“3”的条目。但是如果都改成“,1,5,7,3,92”和“,3,”，因为绝大部分人只有1项，所以也会浪费很多数据库资源
请问有没有人给出终极完美解决方案呢？
...全文
请发表友善的回复…
发表回复
liuyann 2008-05-17
- 打赏
- 举报
假如在一个社区网站，当前用户可能有123个好友，要列举他所有好友的“喜欢的音乐”“喜欢的电影”“喜欢的游戏”“喜欢的运动”“喜欢的书籍”，而它们都是多值字段，可能大部分人每个栏目只填一个，但是有些人比如特别喜欢电影，就会在“喜欢的电影”填50个
我会选择标准的方法。
create table favorites (
userid,
fvType,
fvId
)
==== 思想重于技巧 ====
owen1759 2008-05-17
- 打赏
- 举报
那好，我假设一个情况，看看你会怎么处理？
假如在一个社区网站，当前用户可能有123个好友，要列举他所有好友的“喜欢的音乐”“喜欢的电影”“喜欢的游戏”“喜欢的运动”“喜欢的书籍”，而它们都是多值字段，可能大部分人每个栏目只填一个，但是有些人比如特别喜欢电影，就会在“喜欢的电影”填50个
现在已有Users(记录用户所有详细个人资料)和usrFriends(两个字段，用户ID和好友ID)表
另有一些对应的形如Movies(MovieID,MovieName,简介,导演，演员……)的表
怎么解决这个问题？
无论用以上三种里任何一种都会遇到不可克服的困难，而且严重到不可调和
例如，用第三种，假如某人仅有50个好友，每个好友填了三部电影，那么想要显示影片标题而不是ID，仅仅为了这一个多值字段就要查询150次数据库，因为你要用高级语言把形如“98,56,13”里的ID解析出来，才能一一查询
假如在一个社区网站，当前用户可能有123个好友，要列举他所有好友的“喜欢的音乐”“喜欢的电影”“喜欢的游戏”“喜欢的运动”“喜欢的书籍”，而它们都是多值字段，可能大部分人每个栏目只填一个，但是有些人比如特别喜欢电影，就会在“喜欢的电影”填50个
现在已有Users(记录用户所有详细个人资料)和usrFriends(两个字段，用户ID和好友ID)表
另有一些对应的形如Movies(MovieID,MovieName,简介,导演，演员……)的表
怎么解决这个问题？
无论用以上三种里任何一种都会遇到不可克服的困难，而且严重到不可调和
例如，用第三种，假如某人仅有50个好友，每个好友填了三部电影，那么想要显示影片标题而不是ID，仅仅为了这一个多值字段就要查询150次数据库，因为你要用高级语言把形如“98,56,13”里的ID解析出来，才能一一查询
liuyann 2008-05-16
- 打赏
- 举报
那么,你会选择哪种办法?对于这三种办法各自的缺点,你们会怎么解决?
当然是根据实际应用选一种了。效率，和方便之间取平衡了。不同情况下会有不同选择。 （有些象外交辞令，什么也没回答
）
==== 思想重于技巧 ====
owen1759 2008-05-16
- 打赏
- 举报
那么,你会选择哪种办法?对于这三种办法各自的缺点,你们会怎么解决?
liuyann 2008-05-15
- 打赏
- 举报
不知道楼主想找什么。估计穷其一生也不可能在ACCESS中找到什么完美方案了。
==== 思想重于技巧 ====
owen1759 2008-05-15
- 打赏
- 举报
To 6 楼：
我知道按照《数据结构》课程讲的，尝试二是最标准的做法，但是要考虑一下现实啊。比如你有一个三张表的数据库，A表有3个多值字段，B表有5个，C表有7个，结果打开数据库一看不是很乱七八糟么？
To 7 楼：
看了你推荐的这篇文章，但是这个方法局限性太大了，仅限于ACCESS能支持。我期待的正是用标准SQL的语法，很清晰简洁的实现像ACCESS多值字段的这样效果。
To 8 楼：
我知道这不算什么，但是我是本着一个精益求精的想法求最完美解的。
而且我刚才才想到，看似完美的尝试三有个最严重的麻烦，那就是不能在查询时对此“多值字段”进行数据操作，显然我们显示的时候应该是“张三的兴趣爱好有网球、足球、排球、羽毛球”，而不是“李四的兴趣爱好有1,5,7,3,92”，那么如果要实现这个的话就还要先用高级语言把那些ID们解释出来挨个挨个查询对应的名称，如果某次要列举显示100人的兴趣爱好，其工作量可想而知，因为它无法像单值字段一样“Join”
To changechange：
很谢谢你的热心，虽然我仍然没有找到我要的完美解决
我知道按照《数据结构》课程讲的，尝试二是最标准的做法，但是要考虑一下现实啊。比如你有一个三张表的数据库，A表有3个多值字段，B表有5个，C表有7个，结果打开数据库一看不是很乱七八糟么？
To 7 楼：
看了你推荐的这篇文章，但是这个方法局限性太大了，仅限于ACCESS能支持。我期待的正是用标准SQL的语法，很清晰简洁的实现像ACCESS多值字段的这样效果。
To 8 楼：
我知道这不算什么，但是我是本着一个精益求精的想法求最完美解的。
而且我刚才才想到，看似完美的尝试三有个最严重的麻烦，那就是不能在查询时对此“多值字段”进行数据操作，显然我们显示的时候应该是“张三的兴趣爱好有网球、足球、排球、羽毛球”，而不是“李四的兴趣爱好有1,5,7,3,92”，那么如果要实现这个的话就还要先用高级语言把那些ID们解释出来挨个挨个查询对应的名称，如果某次要列举显示100人的兴趣爱好，其工作量可想而知，因为它无法像单值字段一样“Join”
To changechange：
很谢谢你的热心，虽然我仍然没有找到我要的完美解决
changechange 2008-05-13
- 打赏
- 举报
但是如果都改成“,1,5,7,3,92”和“,3,”，因为绝大部分人只有1项，所以也会浪费很多数据库资源 ----------
一条记录2个字节，你能浪费多少？而且你说只有一项的非常多，就算你有1亿条记录，才浪费 100，000，000字节而已。相对1亿条记录来说，100M 都不到的空间，能算什么？
一条记录2个字节，你能浪费多少？而且你说只有一项的非常多，就算你有1亿条记录，才浪费 100，000，000字节而已。相对1亿条记录来说，100M 都不到的空间，能算什么？
changechange 2008-05-13
- 打赏
- 举报
ACCESS2007如何利用“多值”实现文字的sum《表》
http://access911.net/index.asp?u1=a&u2=72FABE1E16DCECF3
--911--
changechange 2008-05-13
- 打赏
- 举报
尝试二：另外建一个表Relation([intUserID],[intFavourateID])，从这里面查Where intUserID=***。实际上大部分新闻系统的无限级分类就是这样实现的
困难：要是多值字段有好几个，数据库的结构会被弄得一塌糊涂，乱七八糟 -----------------根本无从说起，关系型就是这样，关系非常清晰，一对多关系，哪里来的“乱七八糟”之说？
困难：要是多值字段有好几个，数据库的结构会被弄得一塌糊涂，乱七八糟 -----------------根本无从说起，关系型就是这样，关系非常清晰，一对多关系，哪里来的“乱七八糟”之说？
owen1759 2008-05-12
- 打赏
- 举报
To 1-2 楼:
你说了完全是白说,我既然说了这些尝试都有带来缺陷,怎么还说就用尝试一或者就用尝试二
To 3 楼:
你的想法我已经说了,你仔细看看主帖中"尝试三"的最后一句话.关键还是觉得对数据库有浪费,不够完美.
To 4 楼:
我不知道你说什么,怎样"形成记录"?
你说了完全是白说,我既然说了这些尝试都有带来缺陷,怎么还说就用尝试一或者就用尝试二
To 3 楼:
你的想法我已经说了,你仔细看看主帖中"尝试三"的最后一句话.关键还是觉得对数据库有浪费,不够完美.
To 4 楼:
我不知道你说什么,怎样"形成记录"?
wwwwb 2008-05-12
- 打赏
- 举报
1,5,7,3,92
形成记录检索好一些
1
5
7
3
92
jinshi_cn 2008-05-11
- 打赏
- 举报
[Quote=引用楼主 owen1759 的帖子:]
尝试三：仅一个字段,数据类似“1,5,7,3,92”这样
困难：这个几乎是最完美的方案，但是检索起来将会十分困难，比如你要检索有“3”的，如果检索“3”，就会把“93”“123”都检索进去了，如果检索“,3”“3,”“,3,”就会没检索到仅仅有“3”的条目。但是如果都改成“,1,5,7,3,92”和“,3,”，因为绝大部分人只有1项，所以也会浪费很多数据库资源
[/Quote]
就你的方法三可以进一步完善，把数据“1,5,7,3,92”改为“,1,5,7,3,92,”,也就是每个数字前后都有逗号（当然也可以使用其它的符号，如|），即使只有一项时，该数字前后也各有一个逗号，这样判断是否包含时就可以用前后都有逗号的数字来判断了。如要判断“1,5,7,3,93”或“,3,”中是还包含数值3，就可以用“,3,”来判断了，这样应该就没问题了。至于字段里字符串前后的逗号，在写入前和读取后都可以进行相应的处理。
尝试三：仅一个字段,数据类似“1,5,7,3,92”这样
困难：这个几乎是最完美的方案，但是检索起来将会十分困难，比如你要检索有“3”的，如果检索“3”，就会把“93”“123”都检索进去了，如果检索“,3”“3,”“,3,”就会没检索到仅仅有“3”的条目。但是如果都改成“,1,5,7,3,92”和“,3,”，因为绝大部分人只有1项，所以也会浪费很多数据库资源
[/Quote]
就你的方法三可以进一步完善，把数据“1,5,7,3,92”改为“,1,5,7,3,92,”,也就是每个数字前后都有逗号（当然也可以使用其它的符号，如|），即使只有一项时，该数字前后也各有一个逗号，这样判断是否包含时就可以用前后都有逗号的数字来判断了。如要判断“1,5,7,3,93”或“,3,”中是还包含数值3，就可以用“,3,”来判断了，这样应该就没问题了。至于字段里字符串前后的逗号，在写入前和读取后都可以进行相应的处理。
liuyann 2008-05-10
- 打赏
- 举报
或者就用方法一。
|兴趣爱好1|兴趣爱好2|兴趣爱好3|
==== 思想重于技巧 ====
liuyann 2008-05-10
- 打赏
- 举报
标准的数据库设计来说， 方法二
user (uid,....)
userHobby ( uid,hobid,..)
==== 思想重于技巧 ====
