For example, when I was building a report on Employee's projected availability, I built an employee object and populated that object with references to the relevant dept objects, manager object, etc.
Number crunching???
Those of us in data processing use the term "number crunching" to refer to applications that are computational intensive. You know analog transforms, heavy use of floating point, etc. I wouldn't classify resource tracking/project management software that way. Try signal analysis, ray-tracing. Anything that would be embarassingly parallel!
If you were to build that report in a stored proc, you don't have that option. And the resulting spaghetti SQL is a mess. And the DB has to try and simulate all those relationships in temporary tables, which is sloooooow.
You've just described an application that makes heavy use of aggregation/association and not generalization/specialization. Oddly enough thats why they put the friggin' R in RDBMS. Odd you would think a Join of three tables to be spaghetti. And are you suggesting that RDMSs create temporary tables in doing simple or even comlex joins? Because they don't! The only time temporary tables are created that I am aware of is in doing unions, which in my experience are fairly uncommon. Of course I can only speak for Oracle, SyBase and DB2. And not for amateur home grown non-ANSI 92 compliant stuff like MySQL.
Is this really news to you?
Oh yeah it certainly is, and I always ask for references.
Interesting, I use 'number crunching' to mean an application that crunches numbers -- runs calculations.
You mean you don't understand that?
Odd . . .
And you really don't understand how using OO techniques can speed up running reports on data?
Wow, didn't expect to have to defend the very basis of OO design here. I kinda expected a .NET thread to be about OO techniques.
Let's just say that I disagree. 'Relational' databases have serious limitations in reporting that can easily and quickly be solved with OO techniques. The biggest problem with 'relational' dbs is translating the data into real-world, 'object oriented' records. Someday someone will nail the perfect OO db, I'd bet.
Specifically, as in the example I gave, when the data has relationships that are many-to-many, like employees to projects, using an OO architecture to amalgamate and crunch the data can have serious payoffs in terms of performance and code readibility.
Man, been a while since I've talked to someone that didn't even believe in OO.