问题描述
|
假设我们有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
sid_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;
“ 8”的行为类似于指向结构的指针,数据库将自动连接所需的表。
我知道这还不存在,要成为一个标准可能要花很多时间,我不会在生产就绪的数据库系统中看到它,有些人则不希望它是“看起来很奇怪”。 ”,但我至少想知道是否有可能,如果没有,为什么。
解决方法
数据关系模型的主要优点之一是,它消除了对表之间硬编码链接/指针/导航结构的依赖。数据访问是通过使用关系表达式(如联接)的表和属性名称进行的。
在数据库中保留导航结构的模型的灵活性和动态性较差-更改表结构时,您将使导航结构无效或也必须更改导航结构。您的问题还仅解决那些在外键上恰好相等的联接。联接比这更笼统。
, 第一
Ruby不是SQL,SQL不是Ruby
SQL几乎早于当前所有主流或流行语言
但是,要记住一件事,最重要的是...
重复JOIN与重复查询不同。您会有所不同
在哪里过滤
选择清单
也许是合计
每个查询都是不同的,并且需要不同的索引/计划
使用视图掩盖JOIN将是“封装”它的下一个好主意建议。但是,您最终将获得视图联接视图联接视图...,而视图只是扩展的宏。因此,您的查询将开始运行不佳。
由于不同的过滤器等,使用索引视图可能不是解决方案
从Dems编辑:
这些类型的想法在简单情况下有效,但在复杂情况下会产生更多问题。当前语法在非常广泛的复杂性范围内均能很好/很差地处理基于集合的查询的表达。
, SQL具有
NATURAL JOIN
运算符,例如您的查询将是:
SELECT DISTINCT *
FROM a NATURAL JOIN b;
但是,您似乎想执行一个半联接,对此SQL没有特定的运算符:(
当您对语言设计感兴趣时,请考虑真正的关系语言Tutorial D(为学术目的而设计)具有半联接运算符MATCHING
,例如。您的查询将只是:
a MATCHING b;