John Wood

OR OR RO? More architect disorders...

There's definitely two types of people in this world. There are people who think that databases are the center of the universe, and then there are those that just think the database mostly gets in the way but does offer some useful functions to help you store stuff (ok maybe that's a slight understatement). I'm somewhat of the latter camp. I think the sooner we get C# stored procedures so I don't have to spend all day in Query Analyzer, the better.

Don't get me wrong, I'm all for declarative languages and describing queries with sql, but the tools just aren't as good or as consistent as they could be. For example, if you put a ton of business logic into stored procedures, then how do you put that into source control? How do you guarantee that what is in your production database is what's in your .sql files?

Then I read this post (a guy who thinks that OR mapper should be RO mapper because he starts his designs with the database not the objects) and it brought back all the arguments I've had in the past about how there's more to applications than a bunch of tables and stored procedures.

Starting development with the database is a bit like painting a picture with your eyes closed because you're just not going to see the big picture. It's a simple truth that objects and entity models are higher level than databases. You may be so familiar with databases that you find it natural to design applications faced with a table editor, but you're simply not working with the best tools and your design will certainly suffer as a result.

I'm not vouching for objects either, because I'm certainly not of the deep OO camp. These days I start most of my designs with a good schema editor (XML Spy is quite good, but there are others), and then plan my services that will use this schema. Only then do I find services that need to persist data and then worry about creating tables normalize and store the stuff.

And yes there is a big difference between a schema and a database... schema define documents of data that are even richer than what most OOP languages can define, and are not restricted to data stored in just a database.