Question

假设我们有2个表，a和b：

CREATE TABLE a (id_a INT NOT NULL PRIMARY KEY, id_b INT NOT NULL)
  INDEX fk_id_b (id_b ASC),
    CONSTRAINT fk_id_b FOREIGN KEY (id_b)
    REFERENCES b (id_b);
CREATE TABLE b (id_b INT NOT NULL PRIMARY KEY, b_data INT NOT NULL);

所以a包含以下列：id_a和id_b，其中id_b是b s id_b的外键。当我想从a获取关联的b_data时，我必须进行连接：

SELECT id_a, b_data FROM a JOIN b ON a.id_b=b.id_b;

它工作正常，但它很长，我重复一遍（我不应该根据红宝石家伙的说法），所以我想到了一种方法来使这个查询更简短，更容易理解，仍然是明确的：

SELECT id_a, id_b->b_data FROM a;

foreign_key->column的行为类似于指向结构的指针，数据库会自动加入所需的表。

我知道这不存在，将其作为一个标准可能需要花费很多时间才能在生产就绪数据库系统中看到它而有些人不会想要它“看起来很奇怪”，但我至少想知道，如果有可能，如果没有，为什么。

Answer 1

第一

Ruby不是SQL，SQL不是Ruby
SQL也早于几乎所有当前的主流或时尚语言

但是，要记住一件事，最重要的是......

重复JOIN 与不同，重复查询。你会有不同的

WHERE过滤器
选择列表
可能是聚合

每个都是不同的查询，需要不同的索引/计划

使用视图来掩盖JOIN将是下一个~~好主意~~建议来“封装”它。但是，您最终会看到加入视图加入视图的视图...而视图只是一个扩展的宏。因此，您的查询将开始运行不佳。

使用索引视图可能不是解决方案，因为不同的过滤器等

编辑，来自Dems：

这些类型的想法在简单的情况下起作用，但在复杂的情况下会产生更多的问题。当前语法在很大的复杂性范围内处理基于集合的查询的表达同样好/差。

Answer 2

数据关系模型的一个主要优点是它消除了依赖表之间的硬编码链接/指针/导航结构的需要。使用关联表达式（如连接）通过表和属性名称进行数据访问。

在数据库中持久化导航结构的模型将不那么灵活和动态 - 当您更改表结构时，您将无效或必须更改导航结构。你的问题也只能解决那些恰好是外键上的等同连接的连接。加入比这更普遍。

Answer 3

SQL有一个NATURAL JOIN运算符，例如您的查询将是：

SELECT DISTINCT * 
  FROM a NATURAL JOIN b;

但是，看起来你想要semi-join，而SQL没有特定的运算符：（

由于您对语言设计感兴趣，请考虑真正的关系语言Tutorial D（专为学术目的而设计）有一个半连接运算符MATCHING，例如您的查询只是：

a MATCHING b;

在SQL中“解除引用”外键在理论上是否有效？

3 个答案: