查看: 1348|回复: 11
|
我的database design.. 请大家给点意见
[复制链接]
|
|
我想设计一个类似friendster的网站,就是可以追查到1st to Ten degree的frds有谁...
table_user
UID Name
1001 Jacky
1002 Cindy
1003 Sam
1004 Jack
1005 Yuki
table_friend
UID FriendUID
1001 1002
1002 1003
1003 1004
1004 1005
我用这样的方式来track谁是谁的"downline"...
不懂这样的database structure恰当吗? 可以更好吗? |
|
|
|
|
|
|
|
发表于 7-8-2006 05:12 PM
|
显示全部楼层
原帖由 counterking 于 7-8-2006 04:58 PM 发表
我想设计一个类似friendster的网站,就是可以追查到1st to Ten degree的frds有谁...
table_user
UID Name
1001 Jacky
1002 Cindy
1003 Sam
1004 Jack
1005 Yuki
table_ ...
酱的话 table_friend 就必须COMPOSITE KEY..因为你的PRIMARY KEY回重复。。。
一个UID可以有很多FRIENDS,RELATIONSHIP变MANY TO MANY 了。。
但是我不确定这个是不是最好的方法。。。须问各位大大了。
[ 本帖最后由 弥勒 于 7-8-2006 05:32 PM 编辑 ] |
|
|
|
|
|
|
|
发表于 7-8-2006 06:14 PM
|
显示全部楼层
|
|
|
|
|
|
|
发表于 7-8-2006 11:40 PM
|
显示全部楼层
不需要 composite key, 简单的东西不用设计得那么复杂.
目前来说, 你的设计暂时没什么问题.
只要再设定 foreign key/update/delete relation 就好.
另外, 建议你画 ER 图出来, 否则看的人会很辛苦.
[ 本帖最后由 goatstudio 于 7-8-2006 11:42 PM 编辑 ] |
|
|
|
|
|
|
|
发表于 8-8-2006 11:32 AM
|
显示全部楼层
原帖由 goatstudio 于 7-8-2006 11:40 PM 发表
不需要 composite key, 简单的东西不用设计得那么复杂.
目前来说, 你的设计暂时没什么问题.
只要再设定 foreign key/update/delete relation 就好.
另外, 建议你画 ER 图出来, 否则看的人会很辛苦.
想问他的DATABASE不是MANY-TO-MANY吗??如果这样没有两个FIELD都设AS PRIMARYKEY的话VALUE会重复然后DUPLICATE PRIMARY KEY ERROR 的?? |
|
|
|
|
|
|
|
发表于 8-8-2006 11:35 AM
|
显示全部楼层
原帖由 弥勒 于 8-8-2006 11:32 AM 发表
想问他的DATABASE不是MANY-TO-MANY吗??如果这样没有两个FIELD都设AS PRIMARYKEY的话VALUE会重复然后DUPLICATE PRIMARY KEY ERROR 的??
不在 table_friend 里设 primary key 不就行了? primary key 不一定每一次需要. |
|
|
|
|
|
|
|
发表于 8-8-2006 04:26 PM
|
显示全部楼层
原帖由 弥勒 于 8-8-2006 11:32 AM 发表
想问他的DATABASE不是MANY-TO-MANY吗??如果这样没有两个FIELD都设AS PRIMARYKEY的话VALUE会重复然后DUPLICATE PRIMARY KEY ERROR 的??
我公司里有一个TABLE是记录MOBILE PHONE CALL RECORD的也是没有用PRIMARY KEY的,每天有1百万行RECORD以上。。这种TABLE根本不许要用到PRIMARY KEY。。如果勉强要放PRIMARY KEY的话,就要SET7-8个PK了,如1800XXX的号码。。在同样的CALL DURATION,CALL TIME,CALL COST,PREFIX,COUNTRY,COMMISSION等都可能出现同样的。。。所以不需要有PK,但INDEX用AUTO INC
你会问"没有PRIMARY KEY如何SEARCH DATA"。。答案是为什么一定要有PRIMARY KEY才能SEARCH?哈哈。。老师教你的吗?
MS ACCESS,ORACLE,MS SQL,MYSQL都可以不用set PK嘚
[ 本帖最后由 max5007 于 8-8-2006 04:30 PM 编辑 ] |
|
|
|
|
|
|
|
发表于 9-8-2006 12:39 AM
|
显示全部楼层
原帖由 max5007 于 8-8-2006 04:26 PM 发表
我公司里有一个TABLE是记录MOBILE PHONE CALL RECORD的也是没有用PRIMARY KEY的,每天有1百万行RECORD以上。。这种TABLE根本不许要用到PRIMARY KEY。。如果勉强要放PRIMARY KEY的话,就要SET7-8个PK了, ...
噢。。。谢谢大大。。。
小弟没有经验。。,多谢你们提点。。
偶还真傻。。哈哈。。 |
|
|
|
|
|
|
|
发表于 9-8-2006 09:09 AM
|
显示全部楼层
原帖由 弥勒 于 9-8-2006 12:39 AM 发表
噢。。。谢谢大大。。。
小弟没有经验。。,多谢你们提点。。
偶还真傻。。哈哈。。
分享而已。。我以前的老师也是说一定要放PK的。。可能那老师没有经验,但基本上,多数的TABLE都会SET PK的^^,如果没有PK的TABLE我会用AUTO INCREASE NO当作假的PK^^ |
|
|
|
|
|
|
|
发表于 11-8-2006 11:10 AM
|
显示全部楼层
回复 #9 max5007 的帖子
不太明白呢
table_user
uid
PK(uid)
table_friend
uid
fuid
PK(uid, fuid)
table_friend有PK不是比較好? |
|
|
|
|
|
|
|
发表于 11-8-2006 01:12 PM
|
显示全部楼层
原帖由 cristiano~7 于 11-8-2006 11:10 AM 发表
不太明白呢
table_user
uid
PK(uid)
table_friend
uid
fuid
PK(uid, fuid)
table_friend有PK不是比較好?
我说的是"不是每一个table都要用到PK",而不是针对搂主的题目,根据你说的table,table_friend有pk是好。。可以防止重复的fuid |
|
|
|
|
|
|
|
发表于 28-8-2006 11:11 AM
|
显示全部楼层
PK好像身份证一样
独一无二的
要看大家用处
我个人会比较喜欢加PK(autonumber)
我不知道以后有什么问题(当数据库加大了)
[ 本帖最后由 quantum^_^ 于 28-8-2006 11:14 AM 编辑 ] |
|
|
|
|
|
|
| |
本周最热论坛帖子
|