tag:blogger.com,1999:blog-15319370.post114457693100774037..comments2024-03-05T11:16:00.846+01:00Comments on Roland Bouman's blog: Intelligent SQL JOIN syntax?rpboumanhttp://www.blogger.com/profile/13365137747952711328noreply@blogger.comBlogger12125tag:blogger.com,1999:blog-15319370.post-55705580014291210182020-04-07T19:06:12.734+02:002020-04-07T19:06:12.734+02:00Thanks for sharing you @Bohan! Much appreciated :)...Thanks for sharing you @Bohan! Much appreciated :) rpboumanhttps://www.blogger.com/profile/13365137747952711328noreply@blogger.comtag:blogger.com,1999:blog-15319370.post-74889804987363210342020-04-07T18:24:59.462+02:002020-04-07T18:24:59.462+02:00A side effect of the "a join b using (x, y)&q...A side effect of the "a join b using (x, y)" syntax is that you can no longer refer to the qualified names of the columns that where part of the using clause, i.e. no more "a.x", "a.y", "b.x", "b.y". This makes sense since the origin of x or y doesn't matter anymore, it has to be the same, and stay the same as you add even more joins that made use of those in using clauses. Where this becomes annoying is when you want to put all columns of a table or subquery in the select clause: you are not allowed to do "a.*" nor "b.*" anymore, which i think is a bug in the standard.<br /><br />Anyway, I think the same as you about this syntax being only half-useful or not usable at all if you column naming convention is incompatible. I have no idea why the standardisation committee spent lost their time specifying this and the other natural join (which is an antipattern as you shown), instead of taking advantage of the 99% of tables that can only, unambiguously be joined with one foreign key constraint.<br /><br />Regards<br />bohanhttps://www.blogger.com/profile/02639742284683566272noreply@blogger.comtag:blogger.com,1999:blog-15319370.post-16877172877474697332013-11-07T07:52:24.626+01:002013-11-07T07:52:24.626+01:00Hi 6X,
to the best of my knowledge, nothing has ...Hi 6X, <br /><br />to the best of my knowledge, nothing has changed - there are no databases that implement a feauture like this.<br /><br />I don't know about PG but I think it's highly unlikely that you can add this functionality to MySQL or MariaDB with an "extension" or plugin.<br /><br />You can of course fork the code and add this feature to your own branch. If you can get that to work without changing any other functionality (ie preserve backward compatibility) you might be able to interest MariaDB to accept your patch. <br /><br />That said, I suspect that changing this in MySQL requires serious hacking on both the parser and the query planner. These are very critical, complex parts of the code and I can imagine both MySQL and MariaDB to be very weary of accepting patches for these areas unless they offer substantial benefit for many people (i.e., solve a bug or offer a massive performance enhancement). <br /><br />In other words I think the chances are slim they would change the parser / planner just to add an -apperently not so popular- feature.rpboumanhttps://www.blogger.com/profile/13365137747952711328noreply@blogger.comtag:blogger.com,1999:blog-15319370.post-70883621813201722572013-11-06T22:03:15.209+01:002013-11-06T22:03:15.209+01:00I've also been thinking along this path for qu...I've also been thinking along this path for quite some time but haven't found anything on it until this. Have You seen any development since 2006 on this topic? Would it be possible to add as an extention to PostgreSQL or MariaDB for example?<br />//Best wishes6Xhttps://www.blogger.com/profile/17874484025558284000noreply@blogger.comtag:blogger.com,1999:blog-15319370.post-87629492116208552172010-02-05T11:40:07.023+01:002010-02-05T11:40:07.023+01:00The Article is very good explaining importance of ...The Article is very good explaining importance of different joins<br /><br />It would be more helpful if it provides some general advantages so that beginners can use Joins Properly<br /><br />Also their limitations would help to avoid the complexity while using them by some programmers...<br /><br />Thanks for the Article.......tejasnoreply@blogger.comtag:blogger.com,1999:blog-15319370.post-63070783089521647772009-01-31T12:13:00.000+01:002009-01-31T12:13:00.000+01:00@Anonymous: "nothing mentioned about advantages of...@Anonymous: "nothing mentioned about advantages of joins."<BR/><BR/>I'm afraid I don't understand your remark. This article is not about joins in general, and does not discuss the advantages or disadvantages of the join concept. Rather this article is about the advantages and mainly disadvantages of particular syntax we can use to denote joins in the SQL language. <BR/><BR/>I hope this helps. kind regards,<BR/><BR/>Rolandrpboumanhttps://www.blogger.com/profile/13365137747952711328noreply@blogger.comtag:blogger.com,1999:blog-15319370.post-57955202426127016392009-01-31T08:23:00.000+01:002009-01-31T08:23:00.000+01:00nothing mentioned about advantages of joins.nothing mentioned about advantages of joins.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-15319370.post-13156176887748662832007-09-04T13:48:00.000+02:002007-09-04T13:48:00.000+02:00As always it seems that evolving from one techniqu...As always it seems that evolving from one technique to the next, advantages are created but also lost.<BR/>The Hierarchical and Network Database Models gave us easy path retrieval of nodes either leave stuctured or owner/member like construct closely governed by the design. <BR/>Relational gave us freedom at the same time gave us JOINs to worry about.<BR/>Thanks Roland, good article.<BR/><BR/>Walter (LinkedIn)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-15319370.post-32586025078115672332007-01-03T03:30:00.000+01:002007-01-03T03:30:00.000+01:00I never understood JOINs, now i do!I never understood JOINs, now i do!Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-15319370.post-87908125814123569952006-11-22T18:29:00.000+01:002006-11-22T18:29:00.000+01:00this is good explicated!!!with examplesthis is good explicated!!!with examplesAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-15319370.post-73843420971005941152006-10-20T15:21:00.000+02:002006-10-20T15:21:00.000+02:00hear hear!hear hear!Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-15319370.post-1156813502125759812006-08-29T03:05:00.000+02:002006-08-29T03:05:00.000+02:00this really resonates with me. I am currently tryi...this really resonates with me. I am currently trying to find a faster, easier way to get columns from other tables without having to use the inner join. Though I have defined the relationships between the tables in the InnoDB table structure, I cannot find a fast way to reference the fields. For example, I have a table called events with primary key `id`. I also have another table called counties with primary key `id`. The `events` table has a `county_id` field that refers to the primary key of counties. <BR/><BR/>I have this dream that I will be able to just write SELECT events.name, counties.name FROM events JOIN counties WHERE events.id = 5, because I've already explained to the tables how to relate. Is there a way to do this?Anonymousnoreply@blogger.com