... i wasn't there ... i want to bash that bloke on the head with a large cardboard ampersand. my vote for worst choice of a special character in the history of computing

Bray: "ORM, which really sucks, is based on decades-old thinking, Up until four or five years ago, there were many people, myself among them, who started to think that OR mapping was a bad idea. Then ActiveRecord came along and changed a lot of minds. It got a lot of things right and allowed people to deal with things in a more idiomatic way.”

Google ActiveRecord:

"Active Record connects business objects and database tables to create a persistable domain model where logic and data is presented in one wrapping. It’s an implementation of the object-relational mapping (ORM) pattern by the same name as described by Martin Fowler:

An object that wraps a row in a database table or view, encapsulates the database access, and adds domain logic on that data."

Hello?!? Yeah, big surprise, like there is any way to link RDBMS and OO without ORM.

The ampersand in XML isn't Tim Bray's fault. It comes from SGML and got into HTML long before XML was dreamed of. I'm not sure what character would have been a better choice - caret, perhaps?

...that Gemstone still exists...

but he is right. ORM does suck. Or rather you will think it's great until you need it to perform like an actual OO database. And then you find that no amount of mapping will let you join 12 tables together in less than geological time.

I had three goes at parsing it then gave up.

At a previous job we had a home-brewed ORM running on MS SQL server 2000. There was nothing geological about its performance *provided* stats were kept updated and the final result set was modest (if you get a large result set then it's going to take a long time, full stop).

8- to 12-way joins were common, saw some up in the 25-way (or higher) region though thankfully these were very rare. The DB handled them although the time to optimise these could be a 1/10 second to a couple of seconds on a moderate xeon. Which is not happy-making but was still commercially viable for a decently large multiuser system.

If the query plans could be reused then even the optimisation phase could be bypassed making it very fast in theory, but in practice MS SQL server tended not to keep ad-hoc query plans for medium to large queries.

If you tried running that app on toy DBs which don't have a decent optimiser then quite possibly you could have a new seam of coal ready for the digging by the time it finished. The optimiser is #everything# in DB performance.

The optimizer is a crutch for people who can't design proper schemae. 8- to 12-way joins common? Sounds like some over-normalized academic POS. Or else a data warehouse, but of course most people who have data warehouses know enough to put proper views and reporting tables in place...

>The optimizer is a crutch for people who can't design proper schemae

Err, you what???

The optimiser does a number of things including equivalence-preserving reorderings of joins to minimise the amount of data reads.

Unless you wish to manually write your sql joins to acknowledge the distribution of data in the underlying tables (you don't) and do a bunch of other stuff then you need the optimiser.

As for huge joins, well, it was done that way for a good reason. 'academic' and 'POS' are daft comments unless you know what the product was and why it was designed thus.