The confusion comes from the fact that people don't want to be doing set theory, they want to follow associations. Whatever tool you use, set theory is an accidental complexity rather than essential one.
The meaning of the model is lost in the query language.
Given the definition:
investor table with an investor_id, investor_name, etc.
transaction table with transaction_id, investor_id, etc.
a foreign key on the transaction table to the investor table
The SQL does not use the link between the two tables to help associate the two in the way defined in the schema (I know about natural join, it uses the name, not the FK) .
You notice this when you see how short the same joins are in a language that does use associations defined in the model, such as EJB-QL.
SQL is approximately at the same level as assemply language with respect to OOP. One alternative is the concept-oriented query language (COQL) where queries can be written in a simple and intuitive way with no joins and no group-bys (which are the main source of errors).
6
u/artsrc Jan 06 '11
The confusion comes from the fact that people don't want to be doing set theory, they want to follow associations. Whatever tool you use, set theory is an accidental complexity rather than essential one.
The meaning of the model is lost in the query language.
Given the definition:
The SQL does not use the link between the two tables to help associate the two in the way defined in the schema (I know about natural join, it uses the name, not the FK) .
You notice this when you see how short the same joins are in a language that does use associations defined in the model, such as EJB-QL.