Is Data Decoupling Necessary?
Uncategorized April 2nd, 2008Every two or three projects I work on my client wants to make sure that their application is not tied to the underlying database. They want to have the flexibility to move from SQL Server to Oracle, or even to an open source database like MySQL.
This might seem like a noble desire, but in most cases it isn’t. IBM’s DB2, despite being clumsy, expensive, and very difficult to learn is still going strong. The same goes for Oracle (not to mention the religious fervor surrounding this DB). My point is that the underlying DB almost never changes. I say ‘almost’ because there are rare cases where the underlying DB does need to change. One of those reasons is scalability. MS Access doesn’t scale well. If the backend DB is Access and the application grows significantly then it will have to be changed. Other than that, the only reason I can think of is that a DB vendor makes an incredible offer: "We’ll upgrade all of your database servers and software for free and we’ll pay for the application upgrades just so we can tell the world that your company runs <insert your favorite DB here>". It happens.
So, with that in mind, there is no reason I can think of spend significant time and resources to build a data layer that is completely decoupled from the underlying database. If you start off using SQL Server, then you’ll be using SQL Server 5 years from now on the same project. Once the data layer architecture is complete nobody will want to go in and review those hairy SQL statements to port them over to Oracle or MySQL. It just won’t happen.
Save yourself some time, save your clients some money. Use your DB to its fullest. Take advantage of as many of the built-in performance and usability features as you can to make that application hum.
April 11th, 2008 at 10:01 am
This is the same sort of “thinking” that led C++ programmers to insist on “portable” C++ code. A team I worked on — a team of very bright people, really — made a point of honor out of writing only ANSI Standard C++, with no use of any Windows-specific extensions, and DEFINITELY no MFC. Yes, MFC would eliminate nearly half their work, but gosh darn it, it wouldn’t port to UNIX! Of course, their sales force hadn’t quoted a UNIX system in five years, and there were no UNIX quotes on the horizon; but if customers ever “came to their senses” and moved back to UNIX, these programmers were ready! It made all their projects take longer, but it was worth it!
Meanwhile, they had a maverick. His personal project was all written in MFC. Why was he allowed to go maverick? Well, he started the project at a different company; and then their company bought his company, largely to buy his project. And his project was the ONLY software project in the company that made a profit. (The rest were seen as necessary expenses in a larger hardware system.) So he had power to go his own way.
One day, a salesman came in, trying to pitch them a DEC Alpha solution for a project that needed high performance. To test it out, they wanted to actually hook it up and see how it performed. So they copied the source over. Then they spent ALL DAY porting their “ANSI Standard C++” code so it would run on this new platform.
Meanwhile, they didn’t even want to TRY porting the MFC project, because they “knew” that would mean reimplementing all those MFC-specific functions in ANSI Standard C++. “No, no, no,” the salesman said, “let’s try this third-party MFC-compatibility tool. Yeah, it’s $10K, but that’s only 100 engineering hours. Porting would take longer than that.” So they installed the tool, and then the MFC project.
The MFC guy had to make ONE line of code change, and then his stuff ran.
As Jim McCarthy wrote, “Portability is for canoes.” You chose your platform for its strengths. USE THOSE STRENGTHS!
A lot of this misguided thinking — PARTICULARLY in the DB area — comes from the automotive industry. The Big Three used to have a business model that required them to effectively OWN their suppliers. No, they didn’t own you on paper; but they made up 97% of your revenue stream. If they threatened to move to another supplier, you would do whatever they demanded, else be out of business. So the one thing they absolutely avoided at all cost was vendor lock-in: having a vendor whom they couldn’t replace on a whim. They didn’t LIKE being at the mercy of business decisions they couldn’t control. And their experience with software vendors was that some went out of business, some changed “standards” capriciously, etc. PLUS they would have very heterogeneous networks as they installed or replaced systems across the business. So there was strong pressure to adopt platform-neutral practices, even if they cost more at the local near-term level, because of enterprise and long-term concerns.
And if you’re willing to pay for that sort of concern, fine. But that doesn’t apply in many business that are smaller in scale. Arguably it doesn’t apply even at that level, but it’s hard to get enterprise customers to change their thinking. But on the smaller business scale, not using your tools to their fullest is costing you time and money.
April 11th, 2008 at 10:17 am
But, gosh darnit, if we put in the work up front, and sacrifice just a few niggling little performance enhancement, and hire a few more crack developers that know how to write shrink-wrapped, cross-platform applications, and pay them extra to work on our niche and rather boring project, well… look at all the time and money we’ll save 10 years from now when a newer, more backward compatible OS is released! We can just go through the code and change all of the #ifdef that we stuck to religiously, rebuild all of the string and date manipulation libraries we insisted on building rather than buying, and rewrite all of the SQL statements and, BAM, we’ve got our product ported over.
What’s more, it’ll look like the old OS so our users will love it!