Is the OLTP Programming DBA a Dying Breed?
A number of factors have occurred that make me ask this questions. At the core of this phenomenon I find that hardware is becoming less expensive than the resources necessary to tune your software. I remember when code had to be very small and run efficiently. Today instead of working in a few k of ram, programs ship with libraries that are much larger, and run time engines taking more RAM than a PC could hold only a very few years ago.
So, just as we no longer code in Assembler, then C, followed by C++, now we program in bloated languages like Java and C#. Not because either model is superior…because of Cost. At the end of the day, How Much Working Code can you produce and how much did it cost you? If you can purchase hardware for half the cost of writing smaller, faster, more efficient software, then maybe the best solution is to throw hardware at the problem.
With the adoption of CRUD (Create, Retrieve, Update and Delete) writing tools like Hibernate, nHibernate, Entity Framework and many others, there is little point in hand writing CRUD code today. Why would you even want to?
Since good object design often mirrors fairly closely normalized data, a good software architect may generate a database schema that may not be the ultimate, but will suffice.
Another trend is for the OLTP database engines simply to become CRUD machines. Data Marts, Business Rules, Data Mining, and other key capabilities are being offloaded into other platforms allowing the OLTP database to scream, doing what it does better than any engine available today; CRUD with ACID transactions.
At that point, why hire the Database Architect? Outsource for those times when you need those specific design skills. Hire the Database Administrator to keep the server tuned, and optimize the occasional query. Hire the Data Mining expert for your BI systems. Hire the NoSQL person for the large un-structured day you don’t want to put on your OLTP engine anyway.
Am I missing a trend here? Based on the job postings I see on Monster and elsewhere I don’t think so. It seems companies are satisfied with programmers with a good understanding of SQL and database design. Very few companies are looking for the dedicated Database Architect who can design Relational Schemas and utilize all the neat tricks and coding capabilities a SQL Engine provides.
Here is another indication…Very little of the new features released in the Microsoft SQL Server Engine since 2008 have had anything to do with the database engine. The majority of the updates are built around Business intelligence and Data Mining.
Share your thoughts on this discussion by writing to btaylor@sswug.org.
Cheers,
Ben
$$SWYNK$$
Featured Article(s)
Troubleshooting problems with Analysis Services in SQL Server 2008 R2
This article describes the problems you can have with SQL Server 2008 R2 Analysis Services.
Featured White Paper(s)
All-At-Once Operations
Written by Itzik Ben-Gan with SolidQ
SQL supports a concept called all-at-onc… (read more)