Thanks for the reply and the explanation. Glad to see that we have something similar in Perl. The approach is interesting for me, as I have since always hated writing SQL statements, especially embedded inside Perl.

But now, do lots of people really use this stuff to a moderate degree of complexity in the real-world, in the production? By moderate complexity I mean a set of at least 100 or so tables, queries which is up to a screen in length, 5+ joins, and the like.

But now, do lots of people really use this stuff to a moderate degree of complexity in the real-world, in the production?

I certainly don't. For that matter, I don't usually embed SQL in my code. I prefer to look at a database as a separate service with its own APIs, whether they are implemented as perl with DBI or C with PL/SQL. I feel the data tier should be separately testable and that changes to the database structure should not effect the applications that use it.

By moderate complexity I mean a set of at least 100 or so tables, queries which is up to a screen in length, 5+ joins, and the like.

I feel that if you've got 100 tables, you're likely suffering from bad design. If the schema is not digestible by a single human at a glance, then it's a likely candidate for being broken into multiple co-operative systems.

Similarly, if you're frequently joining over 5 tables, it's probably because you've over-normalized. Normalization is important, but not at the expense of performance and understandability.

There are exceptions: Sequencing over archive tables is a good use of many joins/unions. Joining over many static lookup tables (int -> string) is probably not a good idea - likely you want to fetch and cache the lookup tables to hashes on the client; it's cheaper to send INTs to the client for the main queries.

I have no problem with complicated queries, but I often find that they're mostly unnecessary and/or performance killers. If you treat the database as an API you can layer a minimal amount of code around the database to implement the API. Treated as a separate entity that API is free to implement appropriate caching and replication semantics where they're most useful.

-David

I know this is an old thread but I can't help but adding my 2c. IMO, linq is awesome but only for linq to objects or linq to xml. As a replacement for SQL it's not really that useful imo. It just adds an extra unnecessary layer that makes it more difficult to debug and optimise. It's also more difficult to write and makes it very difficult or impossible to use some of the newer features of a database. It usually reduces performance as it can add extra complexity to the underlying sql. If your motivation is to avoid learning sql then just learn sql.

The only place it could be useful is if you want your app to target a number of databases. However it's probably better just to write simple SQL that will work with many DBs.

Well, in strong typed languages LINQ gives you compile time type checking both within the query and of the result. That's definitely a nice to have, especially in combination with intellisense. In some sense it's a nice way to prototype queries especially since (and now I'm taking about C#/VB.Net) with anonymous types, you can easily and on just one place add some more columns to the result set and have them available right away. No code generation, no changes in different layers, ...

If you then find out that the query got too complex, is not performing well enough or just want to keep all queries in the database, you can change the LINQ query to a stored procedure call.

If the "extra layer" makes it difficult to debug and optimize, then the query has already got too complex and needs to be moved to a stored procedure or hidden in a database view that you can then use in LINQ to go the last step.

Jenda
Enoch was right!
Enjoy the last years of Rome.