当前位置：文江博客话题详情

“有一个”与“属于”与“有很多”用 RDBMS 术语来说

发布于 2024-10-21 08:43:49 字数 166 浏览 1 评论 0原文

有人可以澄清这些在 RDBMS 术语中的含义吗？我总是对这些感到困惑，而且我找不到关于此的任何像样的教程。尝试将定义简化为

链接表
主键
外键

或者告诉我为什么这些定义不能简化为这样简单的东西。不要用 ORM 术语定义它们。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

动听の歌 2024-10-28 08:43:49

编辑：ORM 通常是数据库上的一层非常薄的饰面。通常，类被映射到表，这些类的实例作为表中的行。名为 'USERS' 且具有名为 USERNAME 的 varchar 字段的表可能会映射到名为 User 且具有名为 username 的字符串属性的类。

当映射数据库中的两个表通过外键约束关联时，事情会变得更有趣。 'USERS' 表可能有一个名为 'ID' 的主键，第二个表（例如 'ADDRESSES'）可能包含一个字段称为'USER_ID'，它被限制为'USERS'.'ID'。在这种情况下，用户是独立的，而地址是相关的。 users 表中的行可以取任意值，但是addresses 表中的行必须在users 表中具有对应的行，否则不满足外键约束

。当将其映射到应用程序类时，主键通常会被遮挡。无论如何，应用程序感兴趣的不是 ID。在上面的示例中，我们真正想要的是映射的 Address 类具有 User 类型的属性，即该地址对应的映射用户。同样，我们可能希望 User 类有一个属性，该属性是依赖于它的 Addresses 的集合。

在 ORM 中，独立表称为父类，而从属表则映射到子类。我们在描述这些类时使用的术语是，子类属于父类，这相当于说依赖表对其字段之一具有外键约束，而独立表为所指对象。
相比之下，父类拥有子类，这相当于说独立表是依赖表中字段的外键约束中的引用对象

假设类 A 属于类 B，这样的关系可以是一一对应的，其中每个A可以恰好属于一个B，并且每个B可以恰好有一个A。然而，这是最不常见的情况。大多数情况是一对多，其中每个 A 恰好属于一个 B，但每个 B 可能有零个、一个或多个 A。这样的关系称为一对多。例如，一位用户可以拥有多个电子邮件地址。

最后一个问题是，有时这两个类可能存在多对多关系。这几乎总是通过第三个表来实现。这种关系的一个例子是堆栈溢出问题，它可能有许多标签，每个标签适用于许多问题。一些 ORM 可能认为一个人可以属于另一个人，而无需自反关系，但大多数 ORM 称这种情况为“拥有并属于许多”

EDIT: An ORM is usually a pretty thin veneer over a database. typically, classes are mapped to tables, with instance of those classes as rows in the table. A table named 'USERS' with a varchar field named USERNAME might be mapped to a class named User with a string property named username.

Things get more interesting when two tables in the mapped database are related by a foreign key constraint. The 'USERS' table might have a primary key called 'ID', and a second table, say, 'ADDRESSES' might contain a field called 'USER_ID' which is constrained to 'USERS'.'ID'. In such a case, Users is independent, and Addresses is dependent. A row in the users table may take any value, but rows in the addresses table must have a corresponding row in the users table, else the foreign key constraint is not satisfied

When this is mapped to application classes, primary keys are often occluded. It's not the ID's that the application is interested in anyways. What we really want in the above example is for the mapped Address class to have a property of type User, that is the corresponding mapped user for the address. Similarly, we might want the User class to have a property that is the collection of Addresses that are dependent upon it.

The independent table is called, in the ORM, the parent class, and the dependent table mapped to a child class. The terms we use when describing these classes is that a child class belongs to the parent class, which is equivalent to say that the dependent table has a foreign key constraint on one of its fields with the independent table as the referent.
The Parent class, comparably, has the child class, which is equivalent to saying that the indpendent table is a referent in a foreign key constraint on a field in the dependent table

Supposing class A belongs to class B, Such a relationship may be of a one to one correspondence, where each A can belong to exactly one B, and each B can have exactly one A. This is the least common case, however. Most cases are One to many, where each A belongs to exactly one B, but each B may have zero, one, or more than one A. Such a relationship is called One to many. For instance, a User can have more than one Email address.

The final twist is that sometimes the two classes may be in a many to many relationship. This is almost always achieved by means of a third table. An example of such a relationship is Stack overflow questions, which may have many Tags, and each tag applies to many questions. Some ORM's may have a notion that one can belong to the other without the relationship being reflexive, but most ORM's call this situation "Has and belongs to many"

回复收藏 0 原文