为什么会有“关系”？在数据库上而不是仅仅使用 SQL 的连接？
我总是在数据库文章或教程中看到……在他们使用数据库的任何地方，他们都使用一种称为关系的东西。我立即想到那些带有字段名称列表的小盒子，一个字段用一条线连接到另一个盒子中的另一个字段。
我不是数据库方面的专家（正如您可能知道的那样），但我使用过的一点点，我从来不需要关系。它们似乎总是多余的，因为我总是可以使用 JOIN 来实现在我看来它们的用途。它们是多余的吗？或者有哪些关系是您可以用 JOIN 做而不能做的吗？还是我只是在胡说八道？
I always see in database articles or tutorials or... just everywhere where they use databases, they use a thing called relations. It comes to my mind instantaneously those little boxes with lists of field names and one field connected to another field in another box with a line.
I'm not an expert on databases (as you can probably tell) but the little bit I've used, I never needed relations. They always seemed to be redundant as I can always use JOIN to achieved what it seemed to me they are made for. Are they redundant or is there anything you can do with relations that you cannot do with JOIN? Or am I just talking nonsense?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
关系不仅仅是 SQL 查询的连接。关系提供了许多好处：
数据完整性：
例如，关系有助于确保您的“订单记录”不能在没有“客户记录”的情况下存在。只需定义客户和订单之间的关系，数据库就可以确保这种情况不会发生。这有助于确保你的数据库不会变成一大堆垃圾数据
查询方便：
关系可以使某些类型的查询变得更容易。删除客户记录可以自动同时删除客户的订单，这得益于客户和订单之间的关系
第三方工具集成的好处
许多第三方工具（我想到的是 O/R 工具）依赖于关系才能正常工作。
实际上，这个列表可以一直列下去……你应该使用它们，它们非常有益。即使您今天没有意识到其价值，如果您正在从事一个将在很长一段时间内持续增长的数据库项目，从一开始就建立关系也会对您有利。
我认为它们对于小型项目/一次性数据模型来说并不是那么重要......但对于任何实质性的东西，您最好使用它们。
Relations are not just about joins for SQL queries. Relations provide many benefits:
Data integrity:
Relations help to ensure that your "order records" can't exist without a "customer record" for example. Simply by defining a relationship between customer and order, the database will ensure that this cannot happen. This helps to make sure that your database doesn't become a big pile of junk data
Query convenience:
Relations can make it easier to do certain types of queries. Deleting a customer record can automatically have the customer's orders deleted at the same time, thanks to the relationship between customer and order
Third party tool integration benefits
Many third party tools (O/R tools come to mind) rely on relations in order to work properly
Really, the list could go on and on...you should use them, they're very beneficial. Even if you don't perceive the value today, if you're working on a database project that will continue to grow over a long period of time, it would be to your benefit to set relationships up from the beginning.
I think that they're not that critical for small projects/one-off data models...but for anything of substance, you're better off using them.
RELATION 是一组域的笛卡尔积的子集 (http://mathworld.wolfram.com/ Relation.html）。在日常用语中，关系（或更具体地说是关系变量）是大多数人称为表的数据结构（尽管 SQL 中的表不一定符合关系）。
关系是关系数据库模型的基础。
关系是不同的。关系是语义上的“事物之间的关联”。
我认为您实际上是在询问引用完整性约束（外键）。外键是一种数据完整性规则，通过防止向数据库添加不一致的数据来确保数据库的一致性。不要将外键与关系混淆，因为它们是非常不同的东西。
A RELATION is a subset of the cartesian product of a set of domains (http://mathworld.wolfram.com/Relation.html). In everyday terms a relation (or more specifically a relation variable) is the data structure that most people refer to as a table (although tables in SQL do not necessarily qualify as relations).
Relations are the basis of the relational database model.
Relationships are something different. A relationship is a semantic "association among things".
I think you are actually asking about referential integrity constraints (foreign keys). A foreign key is a data integrity rule that ensures the database is consistent by preventing inconsistent data from being added to it. Don't confuse foreign keys with relations because they are very different things.
我假设当您阅读关系时它可能指的是外键。如果这是真的，那么关系和联接并不是同一问题的不同解决方案。它们是完成不同任务的两种工具，通常一起使用。
正如您所知，联接是选择查询的一部分，它允许您从多个表中获取行。
关系是数据库结构的一部分，它本身定义了规则。例如，如果您有一个城市表和一个国家/地区表，则应该有一个将城市表中的每一行指向国家/地区表中的行的关系。这将确保数据的完整性，并且不允许城市行指向不存在的国家/地区行。
问“当可以使用连接时为什么还要使用关系？”对我来说，这听起来像是在问“为什么变量有类型，而我无论如何都可以读取它们？”。
I'm assuming when you are reading about relations it is probably referring to foreign keys. If that's true, relations and joins are not different solutions for the same problem. They are 2 tools that accomplish different things, and they are usually used together.
A join as it sound like you know is part of a select query that let you get rows from more then 1 table.
A relation is part of the database structure its self that defines a rule. For example if you had a city table and a country table, you should have a relation pointing each row in the city table to a row in the country table. This would ensure the integrity of the data and not allow a city row to point to a country row that doesn't exist.
Asking "Why use relations when you can use joins?" to me sounds like asking 'Why do variables have types when I could read them anyway?".
数据库背后的理论基于关系代数。关系不是数据库特定术语，它源自关系代数。
JOIN 是一种关系，可以有不同类型的关系。请参阅此 wiki 页面以了解有关关系到底是什么的更多信息。
The theory behind databases is based on something called Relational Algebra. Relation is not a database specific term, it is derived from Relational Algebra.
JOIN is kind of Relation, there can be different kind of relations. Refer to this wiki page to know more about what a Relation exactly is.
在关系数据库中建立的关系是关系数据库模型的核心。在数据库中，我们对实体进行建模。我们使用实体之间的关系来维护数据完整性，并确保记录组织正确。关系还在相关表之间创建索引。
如果您没有使用关系，和/或根据离散实体之间的关系对表结构进行建模，那么您就没有利用关系数据库的真正威力。是的，您可以使查询工作，是的，您可以让数据库做一些有用的工作。但是，您能否确保每个员工记录都与正确的公司正确相关？您能否确保该公司只有一条记录，并且该公司的所有员工都与该记录相关？
如果不围绕实体及其之间的关系设计数据库结构，您还不如使用电子表格或一张大而平坦的表格。关系和规范化构成了现代关系数据库的基础。
The relationships established in a RELATIONAL database are the very core of the relational database model. In a database, we model entities. We use relationships between entities to maintain data integrity, and ensure the records are organized properly. Relationships also create indexes between related tables.
If you are not using the relationships, and/or modelling your table structure based upon the relationships between discrete entities, then you are not harnessing the true power of your relational database. Yes, you can make queries work, and yes, you can get the Db to do some usefule work. But can you ensure that, say, every Employee record is properly RELATED to the proper company? Can you ensure that there is only one record for that company, and that all the emplotyees of that company are related to that record?
Without designing your database structure around entities and the relationships between them, you might as well use a spreadsheet, or one big, flat table. RELATIONSHIPS and NORMALIZATION form the basis of the modern relational database.
SQL 表是关系模型关系的近似。表/关系（基础、视图和查询结果）表示关系/关系/关联。这些是盒子和ER（实体关系）和钻石伪 ER 图。此类图上的大多数线条对应于 FK（外键）约束。它们经常被错误地称为“关系”或“关系”，但事实并非如此。它们是事实。 SQL FK 表示表的子行出现在它们是 PK（主键）或 UNIQUE 的其他位置。同样，它表示参与关系/关系/关联的实体也参与另一个关系/关系/关联一次。表含义是必要的&足以查询。约束——包括 PK、UNIQUE 和FK——不需要查询。它们是表关系/关系/关联选择和选择的结果。可能出现什么情况/状态。它们是为了由 DBMS 强制执行完整性。
An SQL table is an approximation of a relational model relation. Tables/relations (bases, views & query results) represent relations/relationships/associations. These are boxes & diamonds on ER (Entity-Relationship) & pseudo-ER diagrams. Most lines on such diagrams correspond to FK (foreign key) constraints. They are frequently but wrongly called "relations" or "relationships" but they are not. They are facts. An SQL FK says that a table's subrows appear elsewhere where they are a PK (primary key) or UNIQUE. Equivalently, it says that an entity participating in a relation/relationship/association also participates once in another one. Table meanings are necessary & sufficient to query. Constraints--including PKs, UNIQUEs & FKs--are not needed to query. They are consequences of the table relation/relationship/association choices & what situations/states can arise. They are for integrity to be enforced by the DBMS.
当 Ed Codd 开发用于大型数据库的数据关系模型时，他的设计基于关系微积分和代数的数学。这种数学的结果是可以用数学精度来预测的，在第一个关系数据库建立之前，Ed Codd 就能够以接近数学精度的方式预测关系数据库的行为。
在数学中，关系是一种数学抽象。正如另一位响应者所说，它是两个或多个域的笛卡尔积的子集。如果这对你来说像泥巴一样清晰，那么也许你不是一个数学家。
不管。优秀的计算机科学家可以相当轻松地理解 SQL 表，并认识和利用 SQL JOIN 的强大功能。对于许多目的来说，这种理解可以代替对关系的数学理解。 SQL 表近似地具体化了一种数学关系。如果你仔细设计表格，你可以把“大约”变成“精确”。
When Ed Codd developed the relational model of data for use with large scale databases, he based his design on the mathematics of relational calculus and algebra. The results of this kind of mathematics is predictable with mathematical precision, and Ed Codd was able to forecast with near mathematical precision how relational databases would behave before the first one was ever built.
In mathematics, a relation is a mathematical abstraction. It's a subset of the cartesian product of two or more domains, as another responder said. If that's as clear as mud to you, maybe you're not a mathematician.
No matter. A good computer scientist can understand SQL tables fairly easily, and recognize and exploit the power of an SQL JOIN. This understanding will do in place of a mathematical understanding of relations for many purposes. An SQL table materializes a mathematical relation, approximately. If you are careful with table design, you can turn "approximately" into "exactly".