How many times we heard :
“I need to map this situation…bla…bla… Note: I can’t touch the DataBase schema.”
“I don’t like composite PK but I can’t change the DB schema.”
“I need to map this situation…bla…bla… Note: legacy DB.”
You can see phrases similar to those above in various NHibernate forums in various languages. The fact that questions are sent to a NH’s forum mean that somebody are developing a new .NET2.0 or .NET3.5 application using NHibernate with an existing DataBase (I’m hoping this is the only possible situation). If a company spent time and money to rewrite an obsolete application for sure is because it is needed.
Let me show another situation: In a new application the first base module was deployed in production. The team now has an existing application with an existing DB and is developing another module. In the second module we realize that some change is needed to the persistence we actually have in production. What the team should do ? Well…something normal for us is create a “migration step” for the DB. The same happen again and again in each sprint.
How much different is the situation when the existing DB is five, or more, years old ? (well… it is different but I’m not so sure that the difference is so big).
“I can’t change the DB because there are other applications using it”… my friend in this case the first step should be write a good service layer to serve “externals” applications.
Why, write a new .NET3.5 application, shouldn’t mean re-think the DB ? The DB is not a part of the old application ?
We are working in software, is the relational DB a piece of granite technology of the past century and nothing more ?
One of my preferred Mentor, illuminate me the way of ORM in these past years, is Scott W. Ambler. If you want help your DBA to come in the XXI century gives him some of Scott’s books. Waiting Christmas point him to this article and invite him to follow each singular link; perhaps you will win a friend.
Dear DBA we are not your enemies, we are both in the same ship.