subject*
And no, I don't mean Llyr. ;-p
Hmm. I guess there are real-world situations that a single table is sufficient to model, but I've never been fortunate enough to work on one. The biggest problem with the JOIN syntax is the fact that it works from left to right, making the occasional 30-table queries rather challenging to debug. Especially when one table is then aliased 6 times, and there are assorted left & right outer joins. Relations are defined as transitive, unless you're mucking about in SQL. *sigh*
And if it's actually faster for you to open one table, retrieve a record, open another table, retrieve all records attached to that ID, close the second table, and iterate... something's probably wrong with your DBMS. Or your (lack of) indices.
But yeah, I'll grant that it is easier to understand the latter, and good enough for a simple web site. Just don't try to convince me that more round trips between your application and the database server are more efficient.
I expect Llyr's math background will both make SQL easier to pick up, and eventually make him groan about how much it mucks up basic relational conepts, in order to make it easier on the DBMS vendors. ("But now it has native XML web services, and built-in inefficient iterative programming. It's buzzword compliant, so nobody who makes purchasing decisions will notice the real structural deficiencies.") |
