Good job ...
... 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
Tim Bray, co-inventor of XML and Sun Microsystems’ Director of Web Technologies, found himself manning “the hangover slot” to give the morning keynote at day two of the Qcon developer conference in San Francisco on Thursday. “And dear god, I’m going to be talking to you about storage,” he said to his limp-but-game audience. “ …
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.”
"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.
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.
Biting the hand that feeds IT © 1998–2019