Of course they were ORM wannabes, but they were buzzword compliant wannabes.
hrothgar
@hrothgar
Best posts made by hrothgar
Latest posts made by hrothgar
-
RE: Stored Procs: Use them or not?
-
RE: Stored Procs: Use them or not?
And when other applications in the enterprise want access to your data? If your data is useful, it doesn't usually take long for other groups within the enterprise to ask for access to your data. If all of the database definitions only exist in the ORM application layer, that data is now inaccessible except through the application.
I just got off (escaped?) a project full of ORM fans who insisted that only old obsolete "fuddy duddies" used stored procedures. Oddly, the ORM advocates spent over a year struggling to get their ORM based application to work, and it was plagued with data integrity and performance problems. Right before I left that project, I finally got approval to use a stored procedure based solution. It took 3 weeks with testing, and no performance or integrity problems. Strangely enough, the ORM advocates always defended the ORM problems, by claiming that, "just one more fix", would make everything work great. The ORM advocates claimed that it was all about saving developer time, it seems to me it cost substantially more developer time to make the ORM stuff work, than a far simplier raw SQL/Stored Procedure solution required. And with the cleaner seperation between the application and the database, when other groups asked for access to the data, it was no big deal, to grant database tier access.
I keep hearing about the "impediance mismatch" between relational databases, and objects. Object Oriented methods are a tool to be used to manage complexity. But it is not the answer to every problem. Functional and procedural methods have their place too. This "impediance mismatch", only exists, because developers insist on using Objects in a way that creates more complexity. Redefine the solution to use the tools where they best fit, and the impediance mismatch goes away.