为什么在理论上比在实践中更多地使用外键? [英] Why are foreign keys more used in theory than in practice?

查看:14
本文介绍了为什么在理论上比在实践中更多地使用外键?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

当您学习关系理论时,外键当然是强制性的.但实际上,在我工作的每个地方,表产品和连接总是通过在查询中明确指定键来完成,而不是依赖 DBMS 中的外键.

When you study relational theory foreign keys are, of course, mandatory. But in practice, in every place I worked, table products and joins are always done by specifying the keys explicitly in the query, instead of relying on foreign keys in the DBMS.

这样,您当然可以通过不应该作为外键的字段连接两个表,从而产生意想不到的结果.

This way, you could of course join two tables by fields that are not meant to be foreign keys, having unexpected results.

你认为这是为什么?DBMS 不应该强制只通过外键进行连接和产品吗?

Why do you think that is? Shouldn't DBMSs enforce that Joins and Products be made only by foreign keys?

感谢所有答案.现在我很清楚 FK 的主要原因是参考完整性.但是,如果您设计数据库,模型中的所有关系(即 ERD 中的箭头)都会成为外键,至少在理论上,无论您是否在 DBMS 中定义它们,它们在语义上都是 FK.我无法想象需要通过不是 FK 的字段来连接表.有人可以举一个有意义的例子吗?

Thanks for all the answers. It's clear to me now that the main reason for FKs is reference integrity. But if you design a DB, all relationships in the model (I.E. arrows in the ERD) become Foreign keys, at least in theory, whether or not you define them as such in your DBMS, they're semantically FKs. I can't imagine the need to join tables by fields that aren't FKs. Can someone give an example that makes sense?

PS:我知道 N:M 关系变成单独的表而不是外键这一事实,为简单起见,将其省略.

PS: I'm aware about the fact that N:M relationships become separate tables and not foreign keys, just omitted it for simplicity's sake.

推荐答案

存在外键约束的原因是为了保证引用的行存在.

外键标识一个表中的一列或一组列,它引用另一个表中的一列或一组列.引用列的一行中的值必须出现在被引用表的单行中.

"The foreign key identifies a column or a set of columns in one table that refers to a column or set of columns in another table. The values in one row of the referencing columns must occur in a single row in the referenced table.

因此,引用表中的行不能包含被引用表中不存在的值(可能为 NULL 除外).这种方式可以将信息链接在一起,这是数据库规范化的重要组成部分."(维基百科)

Thus, a row in the referencing table cannot contain values that don't exist in the referenced table (except potentially NULL). This way references can be made to link information together and it is an essential part of database normalization." (Wikipedia)

RE:您的问题:我无法想象需要按非 FK 字段连接表":

定义外键约束时,引用表中的列必须是被引用表的主键,或者至少是候选键.

When defining a Foreign Key constraint, the column(s) in the referencing table must be the primary key of the referenced table, or at least a candidate key.

连接时,不需要主键或候选键.

When doing joins, there is no need to join with primary keys or candidate keys.

下面是一个有意义的例子:

The following is an example that could make sense:

CREATE TABLE clients (
    client_id       uniqueidentifier  NOT NULL,
    client_name     nvarchar(250)     NOT NULL,
    client_country  char(2)           NOT NULL
);

CREATE TABLE suppliers (
    supplier_id       uniqueidentifier  NOT NULL,
    supplier_name     nvarchar(250)     NOT NULL,
    supplier_country  char(2)           NOT NULL
);

然后查询如下:

SELECT 
    client_name, supplier_name, client_country 
FROM 
    clients 
INNER JOIN
    suppliers ON (clients.client_country = suppliers.supplier_country)
ORDER BY
    client_country;

这些连接有意义的另一种情况是在提供地理空间功能的数据库中,例如 SQL Server 2008 或带有 PostGIS 的 Postgres.您将能够执行以下查询:

Another case where these joins make sense is in databases that offer geospatial features, like SQL Server 2008 or Postgres with PostGIS. You will be able to do queries like these:

SELECT
    state, electorate 
FROM 
    electorates 
INNER JOIN 
    postcodes on (postcodes.Location.STIntersects(electorates.Location) = 1);

来源:ConceptDev - SQL Server 2008 地理:STIntersects, STArea

您可以在帖子Sql 2008 查询问题 - LatLong 存在于地理多边形中的已接受答案中看到另一个类似的地理空间示例?":

SELECT 
    G.Name, COUNT(CL.Id)
FROM
    GeoShapes G
INNER JOIN 
    CrimeLocations CL ON G.ShapeFile.STIntersects(CL.LatLong) = 1
GROUP BY 
    G.Name;

这些都是有效的 SQL 连接,与外键和候选键无关,在实践中仍然有用.

These are all valid SQL joins that have nothing to do with foreign keys and candidate keys, and can still be useful in practice.

这篇关于为什么在理论上比在实践中更多地使用外键?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆