by miclill on 12/18/14, 5:46 PM with 3 comments
by andyjpb on 12/18/14, 5:57 PM
Often a foreign key will refer to rows in more than one other table. Not all queries will want to chase all of those references.
Moreover, when you have a composite key, the foreign part may only be a subset of the entire key.
For example, if your Key is {Street,House}, you have a relation to another table which has a list of people inside that {Street,House} and you might also have a relation on {Street} to a table that contains metadata about that street as a whole.
The "Type" of the "row in another table" isn't a single thing: it would be different for all the different relations so it exists in the form of foreign key declarations which embody all the variability in the relation.
by GFischer on 12/19/14, 12:25 AM
Many ORMs have capabilities for "implicit joins" with either lazy or eager loading of the foreign rows, for example the latest Entity Framework from Microsoft.
http://msdn.microsoft.com/en-us/data/jj713564.aspx
If you like that kind of "automagic" things, check out Genexus:
http://www.genexus.com/global/home?en
it's a 4GL programming environment that has as one of its main strengths that kind of implicit joins and automatic retrieval of data you mention, as long as you follow the naming conventions.
It's a REALLY fast way to build your standard line-of-business application (and it automatically generates iOS and Android apps too), but it falls apart for any other use, and it's UI is not that flexible usually.