Since I’ve come to Sogeti, I’ve met a lot of developers with more experience than myself. This is a good thing, as it allows me to learn from these people and become better at what I do. They have introduced me to processes, ideas, concepts, and methods I had never heard of. One thing that seems to be popular though is the idea of object relational mapping (ORM for short). The idea behind ORM is that there is a layer between your database and your application that maps objects in code to objects in the database. Making data more “object-oriented” and thus easier to program against.
Along with the concept of ORMs comes the idea that data should be more object oriented when it is in the database. The idea of organizing your database structures around the application rather than developing your application around your data. I find issue with this. What I am about to say is probably going to cause of my Alt.Net buddies to flame me, but this is how I feel and my current out look on these ideas.
For a point of reference, I want to point out that I spent years (5 to be exact) developing and supporting applications that revolved around real estate data. The basic idea was to take MLS data and integrate it into a database schema and then use that data in several applications (both web based and windows forms based). So I spent a lot of time working with the data, inside the database. This probably gives me a different perspective than someone who just works with a database rather than in one.
The Argument
Let me get right to the point of my argument. I believe that applications should be developed around the data they view and modify rather than the other way around. The more I read about new development strategies, processes, and methods the more I see people saying this is a bad idea. People seem to have this idea that data should be stored in a more OO way, which would make development easier. Here’s why I think they are wrong.
Data is Relational, Not Object Oriented
Data by its very definition is relational. An address and phone number are tied to a person. A postion, title, and salary are tied to an employee. All data is related to some other piece of data. So the idea that data should be stored in a object model rather than a relational model, completely ignores the very idea of data itself. A piece of data connects to another piece of data and the trend continues on.
Sure, viewing and developing around correctly designed relational databases is never fun, but a good database design looks at how data connects to other pieces of data, not how that data is used progmatically.
Data Drives Applications
Without data, there’d be almost no neeed for applications (unless of course we’re talking about game development). Data drives applications, applications do not drive data. Yes, applications view & modify data but if there was no data, there would be nothing to view or modify would there? This is something a lot of developers forget in their search for the perfect object-oriented database structure. Combine this point with the fact that data is realational, and you have something to really think about when talking about data in relation to application development and design.
I realize that data doesn’t always drive applications, but how many times have you gotten to a job/client and heard this: “We have some data and we’d like to be able to…” This is something I’ve heard a lot. Rarely do you hear “Well we need an application that does XYZ, you’ll be able to store your data here in this database.” Such things happen but the former is more likely in most cases. What I’m arguing here is the idea that an application should drive and help determine how data is stored in a database.
Data is Used in More Than Applications
Data is used for things (often) far beyond the application a developer is designing. Years later, a higher level executive might want to run reports on that data. Companies might use that data to determine their future direction and/or product launches. When you realize this, the object-oriented data design for data doesn’t hold as much water. Sure, your data is in a format that makes the developers job easier, but when you try to relate, things can get complicated.
Conclusion
Hopefully, at the very least, I have given you something to think about. I understand (as a developer) the need to make developing against data easier and more object based. Hence my understanding of the need for ORM tools like NHibernate or the (hated) Entity Framework. I’m not saying that developers shouldn’t find new ways to make data work in their objects, but rather stop the consistant idea that applications should drive data. Data is realtional, it drives the applications that view/modify it, and it is always used for more than you originally intended (always).
Michael Koby 