110,539
社区成员
发帖
与我相关
我的任务
分享我对数据库设计的感悟！
1、我最近终于明白一个理论~
数据库设计中实体关系的是取决与实体间存在的依赖而言,形式为主外关键字段来实现~
也就是说多个实体间如果不存在依赖,就不可能关系~
2、例如:人与蔬菜!
如果要表达人买菜的这个关系就是三个表:人的信息表~~蔬菜信息表~关联买菜的关系表~
3、因为人与菜本身没有关系,如果数据库中要是实现买菜的功能,就要突出"买"这个概念,人要买菜就是人依赖于买的动作,买必须是某个人做出的行为,所以人的信息表与关联买菜的关系表形成了依赖性,既产生了关系!两表通过相应的主外键字段来连接
4、接下来就是关联关系表与蔬菜信息表的关系:蔬菜必须是人买的,所以蔬菜与关联关系表形成了依赖,既产生了关系~~
5、最后总结:人与蔬菜本身没有关系,但是需求中要买菜,就产生了关系,它们之间就通过一个中间表关联起来
数据库设计中实体关系的是取决与实体间存在的依赖而言,形式为主外关键字段来实现~
也就是说多个实体间如果不存在依赖,就不可能关系~
2、例如:人与蔬菜!
如果要表达人买菜的这个关系就是三个表:人的信息表~~蔬菜信息表~关联买菜的关系表~
3、因为人与菜本身没有关系,如果数据库中要是实现买菜的功能,就要突出"买"这个概念,人要买菜就是人依赖于买的动作,买必须是某个人做出的行为,所以人的信息表与关联买菜的关系表形成了依赖性,既产生了关系!两表通过相应的主外键字段来连接
4、接下来就是关联关系表与蔬菜信息表的关系:蔬菜必须是人买的,所以蔬菜与关联关系表形成了依赖,既产生了关系~~
5、最后总结:人与蔬菜本身没有关系,但是需求中要买菜,就产生了关系,它们之间就通过一个中间表关联起来
...全文
请发表友善的回复…
发表回复
wzp144650 2010-04-19
- 打赏
- 举报
[Quote=引用 22 楼 jxyxhz 的回复:]
我现在数据库关联都不建主外键的。。
我觉得我程序逻辑弄好了，要主外键干吗？难道非要数据库那点功能来检测报错？
虽然有人说，主外键是关系数据库的基本东西。。但是我觉得还是以人文本，没问题。。
欢迎有人对此观点，提出有理有据的反驳或分析。。。
[/Quote]
我也这么认为，但没有这么做
我现在数据库关联都不建主外键的。。
我觉得我程序逻辑弄好了，要主外键干吗？难道非要数据库那点功能来检测报错？
虽然有人说，主外键是关系数据库的基本东西。。但是我觉得还是以人文本，没问题。。
欢迎有人对此观点，提出有理有据的反驳或分析。。。
[/Quote]
我也这么认为，但没有这么做
lhd907523077 2010-04-19
- 打赏
- 举报
好，顶下
KEDAXIUCAI 2010-04-19
- 打赏
- 举报
数据库基本表对应现实中的实体分为2种：
1、现实实体（人，物）
2、由现实实体发生具体业务时候演变的实体（各种业务表单、票据等）
我这样的概括对吧？
1、现实实体（人，物）
2、由现实实体发生具体业务时候演变的实体（各种业务表单、票据等）
我这样的概括对吧？
bdx808 2010-01-24
- 打赏
- 举报
[Quote=引用 18 楼 sp1234 的回复:]
其实我一直建议：把自然生活中的语言说好，就建立起最清晰的关联了。不要过分炫耀技术术语，就不会引入有害的成分。太技术化，容易让人走火入魔。
例如你要说清买菜，你的要素是什么？是说明谁买了什么菜。
把这个语言说明白，关联就清晰可见。
[/Quote]
顶一下
其实我一直建议：把自然生活中的语言说好，就建立起最清晰的关联了。不要过分炫耀技术术语，就不会引入有害的成分。太技术化，容易让人走火入魔。
例如你要说清买菜，你的要素是什么？是说明谁买了什么菜。
把这个语言说明白，关联就清晰可见。
[/Quote]
顶一下
林三一 2010-01-24
- 打赏
- 举报
其实我一直建议：把自然生活中的语言说好，就建立起最清晰的关联了。不要过分炫耀技术术语，就不会引入有害的成分。太技术化，容易让人走火入魔。
例如你要说清买菜，你的要素是什么？是说明谁买了什么菜。
把这个语言说明白，关联就清晰可见。
例如你要说清买菜，你的要素是什么？是说明谁买了什么菜。
把这个语言说明白，关联就清晰可见。
黄_瓜 2010-01-24
- 打赏
- 举报
[Quote=引用 18 楼 sp1234 的回复:]
其实我一直建议：把自然生活中的语言说好，就建立起最清晰的关联了。不要过分炫耀技术术语，就不会引入有害的成分。太技术化，容易让人走火入魔。
例如你要说清买菜，你的要素是什么？是说明谁买了什么菜。
把这个语言说明白，关联就清晰可见。
[/Quote]
呵呵，我也喜欢通俗易懂的打比方的方式来描述逻辑。
不喜欢用那些专业术语故弄玄虚
其实我一直建议：把自然生活中的语言说好，就建立起最清晰的关联了。不要过分炫耀技术术语，就不会引入有害的成分。太技术化，容易让人走火入魔。
例如你要说清买菜，你的要素是什么？是说明谁买了什么菜。
把这个语言说明白，关联就清晰可见。
[/Quote]
呵呵，我也喜欢通俗易懂的打比方的方式来描述逻辑。
不喜欢用那些专业术语故弄玄虚
黄_瓜 2010-01-24
- 打赏
- 举报
[Quote=引用 22 楼 jxyxhz 的回复:]
我现在数据库关联都不建主外键的。。
我觉得我程序逻辑弄好了，要主外键干吗？难道非要数据库那点功能来检测报错？
虽然有人说，主外键是关系数据库的基本东西。。但是我觉得还是以人文本，没问题。。
欢迎有人对此观点，提出有理有据的反驳或分析。。。
[/Quote]
外键的主要目的是控制可以存储在外键表中的数据，保证应用完整性，
建立良好的外键关系，在对调试程序逻辑的时候有很大的帮助
我现在数据库关联都不建主外键的。。
我觉得我程序逻辑弄好了，要主外键干吗？难道非要数据库那点功能来检测报错？
虽然有人说，主外键是关系数据库的基本东西。。但是我觉得还是以人文本，没问题。。
欢迎有人对此观点，提出有理有据的反驳或分析。。。
[/Quote]
外键的主要目的是控制可以存储在外键表中的数据，保证应用完整性，
建立良好的外键关系，在对调试程序逻辑的时候有很大的帮助
whb147 2010-01-24
- 打赏
- 举报
[Quote=引用 14 楼 yangglemu 的回复:]
比如微软Aspnetdb库中有一个表Users，有个主键UserID。另外有一个表Roles，有个主键RoleID
还有一个表UserRole，只有两个字段，都是主键（所谓外键）：UserID，RolesID，这样虽然逻辑清楚，但是不是跟面向对象编程一样冗余？
直接在Users中增加一个字段RoleID，省去一个表，不行么？
顺便说一下，楼主这个白菜的例子举得不好
[/Quote]
如果一个人有多个角色呢?,你用一个字段就不好处理了吧
还是用表,用行记录来表示好
比如微软Aspnetdb库中有一个表Users，有个主键UserID。另外有一个表Roles，有个主键RoleID
还有一个表UserRole，只有两个字段，都是主键（所谓外键）：UserID，RolesID，这样虽然逻辑清楚，但是不是跟面向对象编程一样冗余？
直接在Users中增加一个字段RoleID，省去一个表，不行么？
顺便说一下，楼主这个白菜的例子举得不好
[/Quote]
如果一个人有多个角色呢?,你用一个字段就不好处理了吧
还是用表,用行记录来表示好
whb147 2010-01-24
- 打赏
- 举报
[Quote=引用 4 楼 vrhero 的回复:]
数据库设计第三范式...这是数据库设计的基础知识...
[/Quote]
理论上都要到第三范式,有时候,没有必要,也还要照顾一下程序员弟兄
数据库设计第三范式...这是数据库设计的基础知识...
[/Quote]
理论上都要到第三范式,有时候,没有必要,也还要照顾一下程序员弟兄
小_虎 2010-01-24
- 打赏
- 举报
我现在数据库关联都不建主外键的。。
我觉得我程序逻辑弄好了，要主外键干吗？难道非要数据库那点功能来检测报错？
虽然有人说，主外键是关系数据库的基本东西。。但是我觉得还是以人文本，没问题。。
欢迎有人对此观点，提出有理有据的反驳或分析。。。
我觉得我程序逻辑弄好了，要主外键干吗？难道非要数据库那点功能来检测报错？
虽然有人说，主外键是关系数据库的基本东西。。但是我觉得还是以人文本，没问题。。
欢迎有人对此观点，提出有理有据的反驳或分析。。。
flyfly2008 2010-01-24
- 打赏
- 举报
不错，表述得不错，有见第！
KEDAXIUCAI 2010-01-24
- 打赏
- 举报
[Quote=引用 14 楼 yangglemu 的回复:]
比如微软Aspnetdb库中有一个表Users，有个主键UserID。另外有一个表Roles，有个主键RoleID
还有一个表UserRole，只有两个字段，都是主键（所谓外键）：UserID，RolesID，这样虽然逻辑清楚，但是不是跟面向对象编程一样冗余？
直接在Users中增加一个字段RoleID，省去一个表，不行么？
顺便说一下，楼主这个白菜的例子举得不好
[/Quote]
我觉得把Roles表的的RoleID字段放到Users中如果是这样的情况就不妥了 如下：
第一Roles表里的信息是不一样的（Users表里是人的信息，Roles是工资信息）你把RoleID字段给放到Users中去当你删除或者添加人员记录的时候会发生异常（删除张三的信息，那么RoleID字段假设工资号也要删除？工资与人员在设计中是分开的，因为工资是单位里拟定的一个待遇标准，它并不是某个人自身的属性）。
比如微软Aspnetdb库中有一个表Users，有个主键UserID。另外有一个表Roles，有个主键RoleID
还有一个表UserRole，只有两个字段，都是主键（所谓外键）：UserID，RolesID，这样虽然逻辑清楚，但是不是跟面向对象编程一样冗余？
直接在Users中增加一个字段RoleID，省去一个表，不行么？
顺便说一下，楼主这个白菜的例子举得不好
[/Quote]
我觉得把Roles表的的RoleID字段放到Users中如果是这样的情况就不妥了 如下：
第一Roles表里的信息是不一样的（Users表里是人的信息，Roles是工资信息）你把RoleID字段给放到Users中去当你删除或者添加人员记录的时候会发生异常（删除张三的信息，那么RoleID字段假设工资号也要删除？工资与人员在设计中是分开的，因为工资是单位里拟定的一个待遇标准，它并不是某个人自身的属性）。
bcl258586301 2010-01-24
- 打赏
- 举报
。。。
以专业开发人员为伍 2010-01-24
- 打赏
- 举报
其实我一直建议：把自然生活中的语言说好，就建立起最清晰的关联了。不要过分炫耀技术术语，就不会引入有害的成分。太技术化，容易让人走火入魔。
例如你要说清买菜，你的要素是什么？是说明谁买了什么菜。
把这个语言说明白，关联就清晰可见。
例如你要说清买菜，你的要素是什么？是说明谁买了什么菜。
把这个语言说明白，关联就清晰可见。
以专业开发人员为伍 2010-01-24
- 打赏
- 举报
[Quote=引用 15 楼 kedaxiucai 的回复:]
有这样一个数据库表系统：客观实体： 人、蔬菜
如下表体现：人员信息表、事件关联表、事件表、蔬菜信息表四个
人与菜的关系列举出如下动作：人买菜、人吃菜、人洗菜、人炒菜等
要体现人与菜的作用关系：因为人（对象）与蔬菜（对象）的关系是“买、吃、洗、炒”既这就是人对蔬菜做出的行为动作。
首先：人员信息表与事件关联表通过两个表的某字段设置成主外键关联（1:N）关系，然后事件表与事件关联表也通过两个表的某字段设置成主外键关联（1：N）关系,这样就是实现了人与行为的（N:N）关系（一个人可以做出以上四种行为，一个行为同样也可以由多个人做出）。最后事件表的某字段再与蔬菜信息表的相应字段设置成主外键（1：N）关系，如：人虽菜，但可以买多种菜品。
最后推出：人与蔬菜也是（N:N）关系！既：一个人可以买多个菜品，一个菜品也可以由多个人去买（吃、洗、炒）。
[/Quote]
事件跟蔬菜关系？假设一个事件是“拉屎”，跟蔬菜怎么相关？
在设计中，本质上还是以最少的关联来清晰地说明要说明的对象之间的关系为好。不少，更不希望多。
于是，什么是事件？过分“万能”的东西，反而是搞乱关联的。就好象你前面把蔬菜跟买菜关联起来这是很容易理解的，后边把事件跟蔬菜建立起关联则明显有害了。
有这样一个数据库表系统：客观实体： 人、蔬菜
如下表体现：人员信息表、事件关联表、事件表、蔬菜信息表四个
人与菜的关系列举出如下动作：人买菜、人吃菜、人洗菜、人炒菜等
要体现人与菜的作用关系：因为人（对象）与蔬菜（对象）的关系是“买、吃、洗、炒”既这就是人对蔬菜做出的行为动作。
首先：人员信息表与事件关联表通过两个表的某字段设置成主外键关联（1:N）关系，然后事件表与事件关联表也通过两个表的某字段设置成主外键关联（1：N）关系,这样就是实现了人与行为的（N:N）关系（一个人可以做出以上四种行为，一个行为同样也可以由多个人做出）。最后事件表的某字段再与蔬菜信息表的相应字段设置成主外键（1：N）关系，如：人虽菜，但可以买多种菜品。
最后推出：人与蔬菜也是（N:N）关系！既：一个人可以买多个菜品，一个菜品也可以由多个人去买（吃、洗、炒）。
[/Quote]
事件跟蔬菜关系？假设一个事件是“拉屎”，跟蔬菜怎么相关？
在设计中，本质上还是以最少的关联来清晰地说明要说明的对象之间的关系为好。不少，更不希望多。
于是，什么是事件？过分“万能”的东西，反而是搞乱关联的。就好象你前面把蔬菜跟买菜关联起来这是很容易理解的，后边把事件跟蔬菜建立起关联则明显有害了。
以专业开发人员为伍 2010-01-24
- 打赏
- 举报
[Quote=引用 14 楼 yangglemu 的回复:]
比如微软Aspnetdb库中有一个表Users，有个主键UserID。另外有一个表Roles，有个主键RoleID
还有一个表UserRole，只有两个字段，都是主键（所谓外键）：UserID，RolesID，这样虽然逻辑清楚，但是不是跟面向对象编程一样冗余？
直接在Users中增加一个字段RoleID，省去一个表，不行么？
顺便说一下，楼主这个白菜的例子举得不好
[/Quote]
不要说“两个字段，都是主键（所谓外键）”，外键就是外键，不要把外键叫做主键。
Users中增加一个字段RoleID肯定不足，因为Users完全可以具有两个或者更多角色。
比如微软Aspnetdb库中有一个表Users，有个主键UserID。另外有一个表Roles，有个主键RoleID
还有一个表UserRole，只有两个字段，都是主键（所谓外键）：UserID，RolesID，这样虽然逻辑清楚，但是不是跟面向对象编程一样冗余？
直接在Users中增加一个字段RoleID，省去一个表，不行么？
顺便说一下，楼主这个白菜的例子举得不好
[/Quote]
不要说“两个字段，都是主键（所谓外键）”，外键就是外键，不要把外键叫做主键。
Users中增加一个字段RoleID肯定不足，因为Users完全可以具有两个或者更多角色。
KEDAXIUCAI 2010-01-24
- 打赏
- 举报
有这样一个数据库表系统：客观实体： 人、蔬菜
如下表体现：人员信息表、事件关联表、事件表、蔬菜信息表四个
人与菜的关系列举出如下动作：人买菜、人吃菜、人洗菜、人炒菜等
要体现人与菜的作用关系：因为人（对象）与蔬菜（对象）的关系是“买、吃、洗、炒”既这就是人对蔬菜做出的行为动作。
首先：人员信息表与事件关联表通过两个表的某字段设置成主外键关联（1:N）关系，然后事件表与事件关联表也通过两个表的某字段设置成主外键关联（1：N）关系,这样就是实现了人与行为的（N:N）关系（一个人可以做出以上四种行为，一个行为同样也可以由多个人做出）。最后事件表的某字段再与蔬菜信息表的相应字段设置成主外键（1：N）关系，如：人虽菜，但可以买多种菜品。
最后推出：人与蔬菜也是（N:N）关系！既：一个人可以买多个菜品，一个菜品也可以由多个人去买（吃、洗、炒）。
如下表体现：人员信息表、事件关联表、事件表、蔬菜信息表四个
人与菜的关系列举出如下动作：人买菜、人吃菜、人洗菜、人炒菜等
要体现人与菜的作用关系：因为人（对象）与蔬菜（对象）的关系是“买、吃、洗、炒”既这就是人对蔬菜做出的行为动作。
首先：人员信息表与事件关联表通过两个表的某字段设置成主外键关联（1:N）关系，然后事件表与事件关联表也通过两个表的某字段设置成主外键关联（1：N）关系,这样就是实现了人与行为的（N:N）关系（一个人可以做出以上四种行为，一个行为同样也可以由多个人做出）。最后事件表的某字段再与蔬菜信息表的相应字段设置成主外键（1：N）关系，如：人虽菜，但可以买多种菜品。
最后推出：人与蔬菜也是（N:N）关系！既：一个人可以买多个菜品，一个菜品也可以由多个人去买（吃、洗、炒）。
人到中年琐事多 2010-01-24
- 打赏
- 举报
比如微软Aspnetdb库中有一个表Users，有个主键UserID。另外有一个表Roles，有个主键RoleID
还有一个表UserRole，只有两个字段，都是主键（所谓外键）：UserID，RolesID，这样虽然逻辑清楚，但是不是跟面向对象编程一样冗余？
直接在Users中增加一个字段RoleID，省去一个表，不行么？
顺便说一下，楼主这个白菜的例子举得不好
还有一个表UserRole，只有两个字段，都是主键（所谓外键）：UserID，RolesID，这样虽然逻辑清楚，但是不是跟面向对象编程一样冗余？
直接在Users中增加一个字段RoleID，省去一个表，不行么？
顺便说一下，楼主这个白菜的例子举得不好
KEDAXIUCAI 2010-01-24
- 打赏
- 举报
其实我想数据库表分为基础表合关联表.
由此又推演出实体与行为的关联
实体是现实客观的实体对象 如：人 汽车 楼房等
行为是指客观实体的动作 如：吃饭 购物 开车 等客观实体的动作
所以 数据库的实体与关系就是指：客观实体与行为动作之间的关联。如：人开汽车（关联人与汽车客观对象，行是“开”）这样演变到数据库表上就是把人的信息表与汽车的信息表通关表某字段（主外键）或者关联表这样的设计来体现“人开汽车”的关系。
由此又推演出实体与行为的关联
实体是现实客观的实体对象 如：人 汽车 楼房等
行为是指客观实体的动作 如：吃饭 购物 开车 等客观实体的动作
所以 数据库的实体与关系就是指：客观实体与行为动作之间的关联。如：人开汽车（关联人与汽车客观对象，行是“开”）这样演变到数据库表上就是把人的信息表与汽车的信息表通关表某字段（主外键）或者关联表这样的设计来体现“人开汽车”的关系。
ChargeForward 2008-10-09
- 打赏
- 举报
嗯 很经典
加载更多回复（11）
