Question

Suppose we have 2 tables, a and 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);

So a has the following columns: id_a and id_b, where id_b is a foreign key to bs id_b.
When I want to get the associated b_data from a, I have to do a join:

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

It works fine, but it’s long, I repeat myself (which I shouldn’t according to the ruby guys), so I thought of a way to make this query shorter, easier to understand and still unambiguous:

SELECT id_a, id_b->b_data FROM a;

foreign_key->column would behave like a pointer to a structure, the database would automatically join the needed tables.

I know this doesn’t exist, that making it a standard would probably take so much time I wouldn’t live to see it in production ready database systems and some people wouldn’t want it as “it looks weird”, but I would at least like to know, if it would be possible, and if not, why.

Answer 1

One of the major advantages of the relational model of data is that it eliminates the need to rely on hard coded links/pointers/navigational structures between tables. Data access is via table and attribute names using relational expressions like joins.

A model that persisted navigational structures in the database would be less flexible and dynamic – when you changed table structures you would invalidate or have to change the navigational structures as well. Your question also only addresses those joins which happen to be equijoins on foreign keys. Joins are much more general than that.