The database is one of the most important pieces of software in the company. Not always the most important, but probably more important than your code. That’s because your code, if it’s really good, will be rewritten over and over for years, but the data will stick around forever. Look at the two most successful software companies in the world, Microsoft and Oracle. All they do is rewrite their very successful software.
A smart reader may realize that those two companies are selling code and they’d be right. But knowing who will buy that code and what those buyers need the code to do is stored in the database.
He who treats the database as a flat-file repository of data is doomed to burn in Hell. It’s true, I asked.
The two most common, stupid arguments are that “we don’t want the business rules there” and “we don’t want migration problems if we decide to change databases.”
If you were going to waste money and not take advantage of the underlying architecture of an RDBMS, why would you ever need to change database platforms?
If you dissected most failed IT projects, you would find it to be because the architects and seniors were too stupid or too hard headed to respect the database technology and instead opted for an architecture along the lines of doing a select * from database at startup and then not understanding their locking, referential integrity, and scalability issues. If you understand the simplest concepts of SOA, you should know how to successfully work with a database.
One of the biggest problems developers and designers face in this area is that too many DBA’s suck. They cause problems not only for developers and and users, but also for the competent DBA’s out there. And it’s hard enough to be a good DBA without having to worry about the bad ones. If you can find a good database expert, grab her, hold on to her and give her a junior or two to teach her voodoo to and LISTEN to her. Don’t be too stupid to bring in an outside consultant to help you find the right candidate, it’s worth a couple of grand.