如果我们可以从两个表中获取数据而没有主键和外键关系,那么为什么我们需要这个规则呢？你能用合适的例子清楚地解释我吗？这是一个测试数据库,不介意坏结构.
表的结构:
**
table - 'test1'
columns - id,lname,fname,dob
no primary and foreign key and also not unique(without any constraints)
**
**table - 'test2'
columns- id,native_city
again, no relations and no constraints**
我仍然可以使用相同的列'id'连接这些表,所以如果没有主外键,那么它的用途是什么？
Dan*_*haw 60
主键和外键的主要原因是强制数据一致性.
主键强制在一列或多列上保持值唯一性的一致性.如果ID列具有主键,则不可能有两个具有相同ID值的行.如果没有该主键,许多行可能具有相同的ID值,您将无法仅根据ID值区分它们.
外键强制指向其他位置的数据的一致性.它确保指向的数据实际存在.在典型的父子关系中,外键确保每个子节点始终指向父节点并且父节点实际存在.如果没有外键,您可能会有"孤儿"的孩子指向不存在的父母.
duf*_*ymo 20
您需要两个相同类型的列,每个表一个,以加入.无论是主键还是外键都没关系.
Jen*_*der 17
您不需要FK,可以加入任意列.
但是使用外键可确保连接实际上能够成功找到某些内容.
外键为您提供某些保证,这些保证极其困难且容易出错.
例如,如果您没有外键,则可以在系统中插入详细记录,并在检查到匹配的主记录存在之后,其他人将其删除.因此,为了防止这种情况,您需要在修改详细信息表时锁定主表(反之亦然).如果您不需要/想要保证,请拧紧FK.
根据您的RDBMS,外键也可能会提高select的性能(但也会降低更新,插入和删除的性能)
我知道它的发布时间较晚,但我使用该网站供我自己参考,所以我想在这里给自己一个答案,以便将来参考.我希望你(和其他人)觉得它有用.
让我们假装一群超级爱因斯坦专家设计我们的数据库.我们的超级完美数据库有3个表,它们之间定义了以下关系:
TblA 1:M TblB
TblB 1:M TblC
Notice there is no relationship between TblA and TblC
在大多数情况下,这样一个简单的数据库很容易导航,但在商业数据库中,通常不可能在设计阶段告诉数据,表甚至整个数据库的所有可能的用途和用途组合,特别是当系统得到时基于和其他系统集成或切换或切换.这个简单的事实催生了一个建立在名为Business Intelligence的数据库之上的整个行业.但我离题了......
在上面的例子中,结构很容易理解,很容易看出你可以从TblA,到B,再到C,反之亦然,以获得你需要的东西.它也非常模糊地强调了这样做的一些问题.现在将这个简单的链扩展到10或20或50个关系.现在突然间你开始想象出对你的场景的需求.简单来说,从A到C的连接或反之亦然,或A到F或B到Z的连接或者我们系统增长的任何连接.
有很多方法可以做到这一点.上面提到的那个是最受欢迎的,即通过所有链接.主要问题是它非常慢.并且随着您添加到链中的表越多,速度越慢,这些表的增长越多,您想要进一步完成它.
解决方案1:寻找共同的链接.如果你教会了加入A到C的理由,那一定是在那里.如果不明显,建立一个关系,然后加入它.即要加入A到B到C,必须有一些共性,否则你的连接会产生零结果或大量数字或结果(笛卡尔积).如果您知道这种共性,只需将所需的列添加到A和C并直接链接它们.
关系规则是他们必须有理由存在.而已.如果你能找到一个很好的理由从A链接到C,那就去做吧.但是你必须确保你的理由不是多余的(即它已经以其他方式处理).
现在一句警告.有一些陷阱.但是我没有很好地解释它们,所以我会把你推荐给我的来源,而不是在这里谈论它.但请记住,这是一些沉重的东西,所以这个关于粉丝和裂缝陷阱的视频实际上只是一个起点.你可以没有关系加入.但我建议首先观看这个视频,因为这超出了大多数人在大学里学到的东西以及BI和SAP人员的领域.这些家伙,虽然他们可以编程,但他们的日常工作是专注于这种事情.如何获取大量数据以便彼此交流并有意义.
这个视频是我在这个主题上遇到过的最好的视频之一.值得一看其他一些视频.我从他身上学到了很多东西.
| 归档时间： |
|
| 查看次数： |
101875 次 |
| 最近记录： |