在SQL中"解除引用"外键在理论上是否有效?

tst*_*ner 1 sql language-design foreign-keys

假设我们有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);
Run Code Online (Sandbox Code Playgroud)

所以a有以下列:id_aid_b,其中id_bbs 的外键id_b.当我想从a获取关联的b_data时,我必须进行连接:

SELECT id_a, b_data FROM a JOIN b ON a.id_b=b.id_b;
Run Code Online (Sandbox Code Playgroud)

它工作正常,但它很长,我重复自己(我不应该根据红宝石家伙),所以我想到了一种方法,使这个查询更短,更容易理解,仍然是明确的:

SELECT id_a, id_b->b_data FROM a;
Run Code Online (Sandbox Code Playgroud)

foreign_key->column 就像指向结构的指针一样,数据库会自动加入所需的表.

我知道这不存在,将其作为标准可能需要花费很多时间才能在生产就绪的数据库系统中看到它并且有些人不希望它"看起来很奇怪",但我会至少想知道,如果有可能,如果没有,为什么.

gbn*_*gbn 8

第一

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

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

重复该JOIN 是不一样的重复查询.你会有不同的

  • WHERE过滤器
  • 选择列表
  • 也许是一个聚合

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

使用视图来掩盖JOIN将是下一个"封装"它的好主意建议.但是,您最终会看到加入视图加入视图的视图...而视图只是一个扩展的宏.所以你的查询将开始运行不佳.

由于不同的过滤器等,使用索引视图可能不是解决方案

来自Dems的编辑:

这些类型的想法在简单的情况下工作,但在复杂的情况下会产生更多的问题.当前语法在非常广泛的复杂性中同样良好/差地处理基于集合的查询的表达.

  • 我试图说出gbn所说的一种方式是:这些类型的想法在简单的情况下起作用,但在复杂的情况下会产生更多的问题.当前语法在非常广泛的复杂性中同样良好/差地处理基于集合的查询的表达. (4认同)