带有外键的数据库。描绘前向与后向关系的好方法?

在任何关系型数据库系统中,我们都可以有一个父模型和一个子模型(它存储着父的外键)。

虽然我在实际工作中使用这些就很好,但这些经常被描述为 “前向关系 “或 “reverseingbackrefrelated_namegoing backward “的方式本身在我看来总是很倒退!

比如,很多资料和文章把从子代到父代描述为 “前向外键”。 但是当我想象一棵树时,我从最上面的父节点开始,我把向下遍历它看作是 “正向”,这与其他地方把从父–> 子描述为反向或反向关系的方式相反。

有没有人有一个解释这种命名方式的理由,可以帮助我记住这一点? 或者你想象的方法? 我在这个话题上找了一圈,没有发现有人讨论这个约定俗成的术语(只是如何用它来编码)。

解决方案:

在关系模型中,关系(ship)关联是由表来表示的。FK(外键)约束不是关系,虽然它们被错误地称为关系。它们是约束,不需要被声明、已知或存在来查询。一个FK约束规定,值在其他地方出现一次。或者等价的说,一起参加某个关系的值一起参加某个其他关系一次。”父 “与 “子 “适用于任何树形结构或其他层次结构的关系&”向前 “与 “向后 “是通用术语,适用于任何方向的定向二元关系–包括表上的元关系 “有一个引用的FK “或 “出现一次在”。不过这其实并不是叫FKs “关系 “的产生方式)。

只是有共同的约定……包括对于 “树”……有趣的是,外面的树从根部往上走,而不是往下走。计算机科学的树往下走只是另一个惯例……对于西方人来说,从上往下写,往空间大的地方写。虽然有些约定俗成可能有特别的原因,但没有必要担心它们是否有意义或是否一致。

我们说一个FK引用了一个PK,所以像英语一样从左往右读,我们可以称之为 “前进”。FK可以形成关系上的循环,但是SQL DBMS倾向于限制声明为树,因为他们用级联功能&不屑于允许dags或循环。所以在SQL中,parent是引用&child是引用。但是SQL的FK不是关系型FK的类比,它们是我们可以称之为关系型外链超键的类比。所以就出现了 “FK “超载。

没有理由期待一致性。法国吐司不是吐司。关系不是关系。

不要使用这些通用术语。 相反,清楚地确定你所谈论的关系(ship)sassociations,命名和或排序它们的参数,并正确使用正确的技术术语,如 “引用”&”引用”。需要我说你必须 熟记专业术语的定义? 或者对于通用术语,按照这个要求,定义一下你要在每个具体的语境中对通用术语使用什么具体的含义。(但你这样做只是在自找误解)。

在数据库设计中,说父子表是不是不对?

给TA打赏
共{{data.count}}人
人已打赏
未分类

如何解决Shapes.PasteSpecial:无效请求时粘贴位图?

2022-9-8 4:13:32

未分类

将VBA表格连接到Outlook应用程序

2022-9-8 4:13:34

0 条回复 A文章作者 M管理员
    暂无讨论,说说你的看法吧
个人中心
购物车
优惠劵
今日签到
有新私信 私信列表
搜索