Comments on: The Cost Of Database Independence http://www.rittmanmead.com/2004/11/24/the-cost-of-database-independence/ Delivered Intelligence Wed, 10 Mar 2010 20:28:28 -0500 http://wordpress.org/?v=2.8.4 hourly 1 By: David Aldridge http://www.rittmanmead.com/2004/11/24/the-cost-of-database-independence/comment-page-1/#comment-204 David Aldridge Thu, 28 Dec 2006 00:54:38 +0000 http://www.rittmanmead.com/wp2/2004/11/24/the-cost-of-database-independence/#comment-204 It's an interesting paradox, that forcing database independence is intended to make the enterprise more cost effective by reducing potential licensing costs, however the method makes applications less cost-effective themselves through requiring more expensive hardware, and that more CPU's mean higher licensing costs whatever platform is chosen. So it doesn't actually make economic sense as well as being technologically a poor practice. It’s an interesting paradox, that forcing database independence is intended to make the enterprise more cost effective by reducing potential licensing costs, however the method makes applications less cost-effective themselves through requiring more expensive hardware, and that more CPU’s mean higher licensing costs whatever platform is chosen.

So it doesn’t actually make economic sense as well as being technologically a poor practice.

]]> By: Savitha Malve http://www.rittmanmead.com/2004/11/24/the-cost-of-database-independence/comment-page-1/#comment-203 Savitha Malve Mon, 06 Dec 2004 13:24:00 +0000 http://www.rittmanmead.com/wp2/2004/11/24/the-cost-of-database-independence/#comment-203 Why re-invent a wheel when we already have one built in.There is no point in discarding built in features after buying a product which is efficient in handling things we want and waste couple of days of time to find other options. Why re-invent a wheel when we already have one built in.There is no point in discarding built in features after buying a product which is efficient in handling things we want and waste couple of days of time to find other options.

]]> By: H.Tonguc YILMAZ http://www.rittmanmead.com/2004/11/24/the-cost-of-database-independence/comment-page-1/#comment-202 H.Tonguc YILMAZ Mon, 06 Dec 2004 07:13:00 +0000 http://www.rittmanmead.com/wp2/2004/11/24/the-cost-of-database-independence/#comment-202 One of the most interesting example of database independence may be seen in JDBC programming in my opinion. Since JDBC is a standart java guys talk about this as an advantage, but here are some test results for improving the performance of J2EE applications with very simple JDBC tips; Total time for inserting 2000 rows to a simple oracle table was 9499 milliseconds initially Disabling auto-commit mode, With Prepared Statement, Batching with batch size = 30 Total time for inserting 2000 rows was 311 milliseconds, ~%97 gain… Even with Pl/Sql Bulk operations same operation can be done under 50 milliseconds.. (Other simple features like Row PreFetching, Defining the Types of Result Set Columns, Statement Caching also affects the performance very much - Oracle 9i JDBC Programming by Jason Price) In my organization this independence efforts and the black-box syndrome like Kyte mentions(Expert One-on-One by Thomas KYTE) minimize our investment for Oracle and makes me a magician since with the very small knowledge which is available everywhere I can improve an application’s performance 2-3 times.. Lately the java develpers I work with needed a search tool for their internet application, the project manager started to investigate the available tools. At that moment I heard about this and talked with the manager of the group and suggested them to use Oracle Text since they are running on Oracle9iR2. The result were as usual, I was once again a magician :o)) Developers who work with Oracle must know what is available for them, if not “database indepedence” guide people to run on Oracle like an Excel sheet and reinvent the wheel again and again in every new project.. Best regards. One of the most interesting example of database independence may be seen in JDBC programming in my opinion. Since JDBC is a standart java guys talk about this as an advantage, but here are some test results for improving the performance of J2EE applications with very simple JDBC tips;
Total time for inserting 2000 rows to a simple oracle table was 9499 milliseconds initially
Disabling auto-commit mode,
With Prepared Statement,
Batching with batch size = 30
Total time for inserting 2000 rows was 311 milliseconds, ~%97 gain…
Even with Pl/Sql Bulk operations same operation can be done under 50 milliseconds..
(Other simple features like Row PreFetching, Defining the Types of Result Set Columns, Statement Caching also affects the performance very much – Oracle 9i JDBC Programming by Jason Price)
In my organization this independence efforts and the black-box syndrome like Kyte mentions(Expert One-on-One by Thomas KYTE) minimize our investment for Oracle and makes me a magician since with the very small knowledge which is available everywhere I can improve an application’s performance 2-3 times..
Lately the java develpers I work with needed a search tool for their internet application, the project manager started to investigate the available tools. At that moment I heard about this and talked with the manager of the group and suggested them to use Oracle Text since they are running on Oracle9iR2. The result were as usual, I was once again a magician :o))
Developers who work with Oracle must know what is available for them, if not “database indepedence” guide people to run on Oracle like an Excel sheet and reinvent the wheel again and again in every new project..
Best regards.

]]> By: Stew Stryker http://www.rittmanmead.com/2004/11/24/the-cost-of-database-independence/comment-page-1/#comment-201 Stew Stryker Tue, 30 Nov 2004 21:33:00 +0000 http://www.rittmanmead.com/wp2/2004/11/24/the-cost-of-database-independence/#comment-201 As Sebastiano Pilla wrote: They could’ve achieved a good compromise by encapsulating the sequence retrieval function in a module (very loosely speaking, I don’t know the programming language used), and using one implementation for Oracle (Oracle sequences) and another implementation for another database. The amount of code that differs from one database to another would still be very small and they could obtain satisfactory performance. I agree entirely. If you’ll pardon the metaphor, here’s my view of “database independence”. Let’s say you buy a car. You ski, snowboard and kayak, so you buy a Thule roof rack with all the doodads to attach them to this car. A few years later, you trade the car in for a different brand and type. If you expect to be able to strap the old roof rack on your new vehicle, you’re going to be disappointed because 8 times out of 10, it ain’t going to work. But you don’t have to buy a whole new rack and ski, snowboard and kayak attachments. You just have to buy new feet for the rack bar. So those vehicle-specific feet are equivalent to those database-specific modules that you’ll have to maintain when you move to a new database. Thinking you’re going to get 100% future compatibility with a new database (or new car) is foolish. As Sebastiano Pilla wrote:
They could’ve achieved a good compromise by encapsulating the sequence retrieval function in a module (very loosely speaking, I don’t know the programming language used), and using one implementation for Oracle (Oracle sequences) and another implementation for another database. The amount of code that differs from one database to another would still be very small and they could obtain satisfactory performance.
I agree entirely.
If you’ll pardon the metaphor, here’s my view of “database independence”. Let’s say you buy a car. You ski, snowboard and kayak, so you buy a Thule roof rack with all the doodads to attach them to this car. A few years later, you trade the car in for a different brand and type. If you expect to be able to strap the old roof rack on your new vehicle, you’re going to be disappointed because 8 times out of 10, it ain’t going to work. But you don’t have to buy a whole new rack and ski, snowboard and kayak attachments. You just have to buy new feet for the rack bar.
So those vehicle-specific feet are equivalent to those database-specific modules that you’ll have to maintain when you move to a new database. Thinking you’re going to get 100% future compatibility with a new database (or new car) is foolish.

]]> By: Dan Clamage http://www.rittmanmead.com/2004/11/24/the-cost-of-database-independence/comment-page-1/#comment-200 Dan Clamage Mon, 29 Nov 2004 20:41:00 +0000 http://www.rittmanmead.com/wp2/2004/11/24/the-cost-of-database-independence/#comment-200 Is database independence what they’re teaching in universities these days? Some professors are really out of touch with the real world, where we have to make things work quickly and scale well. A well-known Best Practice (that has been proven to work) is to encapsulate your SQL in an interface layer, so when you have to go changing things for another target database, that’s the only thing you have to muck with. The application layer (however you wish to implement it, 2-tier, 3-tier or n-tier) shouldn’t have to change. This is how we design and build highly maintainable systems (where you make few or no changes to the software whenever business requirements change). What would really aid database migration projects is a translator that takes PL/SQL for example and turns it into T-SQL. But I think a cross-platform, robust translator is a long ways off. Is database independence what they’re teaching in universities these days? Some professors are really out of touch with the real world, where we have to make things work quickly and scale well. A well-known Best Practice (that has been proven to work) is to encapsulate your SQL in an interface layer, so when you have to go changing things for another target database, that’s the only thing you have to muck with. The application layer (however you wish to implement it, 2-tier, 3-tier or n-tier) shouldn’t have to change. This is how we design and build highly maintainable systems (where you make few or no changes to the software whenever business requirements change).
What would really aid database migration projects is a translator that takes PL/SQL for example and turns it into T-SQL. But I think a cross-platform, robust translator is a long ways off.

]]> By: Kim N rby Andersen http://www.rittmanmead.com/2004/11/24/the-cost-of-database-independence/comment-page-1/#comment-199 Kim N rby Andersen Fri, 26 Nov 2004 08:46:00 +0000 http://www.rittmanmead.com/wp2/2004/11/24/the-cost-of-database-independence/#comment-199 Allow me to disagree to some point. Actually database independence is a good thing - and I’m right out of school. My point is that to ensure gaining a broader market, one must be able to deploy “anywhere”, using most large vendors. However, I seek it through an alternative strategy, compared to the “tables and indexes” way. I believe that Object Oriented Programming should supply the application with a data abstraction layer, with a complete interface (here, I mean the interface keyword, as used in C++, java og C#), and allowing you to use the “Oracle app layer”, “MSSQL layer” or the “Tables and indexes” layer. Anyways, I’m ready to debate this in further detail, if anybody should wish so :) Yours Kim Allow me to disagree to some point. Actually database independence is a good thing – and I’m right out of school. My point is that to ensure gaining a broader market, one must be able to deploy “anywhere”, using most large vendors.
However, I seek it through an alternative strategy, compared to the “tables and indexes” way. I believe that Object Oriented Programming should supply the application with a data abstraction layer, with a complete interface (here, I mean the interface keyword, as used in C++, java og C#), and allowing you to use the “Oracle app layer”, “MSSQL layer” or the “Tables and indexes” layer.
Anyways, I’m ready to debate this in further detail, if anybody should wish so :)
Yours
Kim

]]> By: Alan Green http://www.rittmanmead.com/2004/11/24/the-cost-of-database-independence/comment-page-1/#comment-198 Alan Green Fri, 26 Nov 2004 05:12:00 +0000 http://www.rittmanmead.com/wp2/2004/11/24/the-cost-of-database-independence/#comment-198 There’s a balance here between a working application and remaining reasonably flexible to choose between RDBMS implementations. Rather than completely embracing vendor specific extensions, we tend to write fairly generic SQL for the easy 80% of an application and then do whatever it takes to make the hard 20% work well. There’s a balance here between a working application and remaining reasonably flexible to choose between RDBMS implementations. Rather than completely embracing vendor specific extensions, we tend to write fairly generic SQL for the easy 80% of an application and then do whatever it takes to make the hard 20% work well.

]]> By: Sebastiano Pilla http://www.rittmanmead.com/2004/11/24/the-cost-of-database-independence/comment-page-1/#comment-197 Sebastiano Pilla Thu, 25 Nov 2004 17:57:00 +0000 http://www.rittmanmead.com/wp2/2004/11/24/the-cost-of-database-independence/#comment-197 They could’ve achieved a good compromise by encapsulating the sequence retrieval function in a module (very loosely speaking, I don’t know the programming language used), and using one implementation for Oracle (Oracle sequences) and another implementation for another database. The amount of code that differs from one database to another would still be very small and they could obtain satisfactory performance. They could’ve achieved a good compromise by encapsulating the sequence retrieval function in a module (very loosely speaking, I don’t know the programming language used), and using one implementation for Oracle (Oracle sequences) and another implementation for another database. The amount of code that differs from one database to another would still be very small and they could obtain satisfactory performance.

]]> By: Mr. Ed http://www.rittmanmead.com/2004/11/24/the-cost-of-database-independence/comment-page-1/#comment-196 Mr. Ed Thu, 25 Nov 2004 06:26:00 +0000 http://www.rittmanmead.com/wp2/2004/11/24/the-cost-of-database-independence/#comment-196 “Database independent” seems to mean that an application _works at all_. No one seems to include the notion that the app has to also _work with reasonable performance_. It’s like saying that you can stop programming once you get the program to compile. You can have severe problems on other databases. For example, DB2’s locking mechanism is vastly different from Oracle’s, and an elaborate scheme to reproduce a feature can lock up hard (think: an Oracle app meets lock escalation on DB2). I have seen companies switch from one database to another, and things like this always nip them in the behind. A better goal is to only use SQL/features/code that can be easily reproduced on other database types. Every database seems to have the equivalent of a sequence, so there’s nothing wrong with using it. But if you get into some of the fancier Oracle, DB2, or Sybase features, you start to dramatically increase your work if you need to convert. Companies will spend a lot more money trying to make their “database independent” code work on every database then to simply use the constructs that the database vendor has provided. After all, you’re not creating the index leaves yourself, anymore, right? “Database independent” seems to mean that an application _works at all_. No one seems to include the notion that the app has to also _work with reasonable performance_. It’s like saying that you can stop programming once you get the program to compile.
You can have severe problems on other databases. For example, DB2’s locking mechanism is vastly different from Oracle’s, and an elaborate scheme to reproduce a feature can lock up hard (think: an Oracle app meets lock escalation on DB2). I have seen companies switch from one database to another, and things like this always nip them in the behind.
A better goal is to only use SQL/features/code that can be easily reproduced on other database types. Every database seems to have the equivalent of a sequence, so there’s nothing wrong with using it. But if you get into some of the fancier Oracle, DB2, or Sybase features, you start to dramatically increase your work if you need to convert.
Companies will spend a lot more money trying to make their “database independent” code work on every database then to simply use the constructs that the database vendor has provided. After all, you’re not creating the index leaves yourself, anymore, right?

]]> By: Andy Todd http://www.rittmanmead.com/2004/11/24/the-cost-of-database-independence/comment-page-1/#comment-195 Andy Todd Thu, 25 Nov 2004 02:12:00 +0000 http://www.rittmanmead.com/wp2/2004/11/24/the-cost-of-database-independence/#comment-195 Great piece Mark, well written and argued. I’d go one step further and say that every database solves this problem in a different way, each of which is more efficient than using a table of sequences. In MySQL, for instance, they have the auto_increment column. A side effect of this is some arguably not great database designs where every table has an artificial key even if it doesn’t require one. This is usually because the person designing the schema *knows* that the definition of a primary key column is and that every table needs one. [1] <a href="http://dev.mysql.com/doc/mysql/en/example-AUTO_INCREMENT.html" rel="nofollow">http://dev.mysql.com/doc/mysql/en/example-AUTO_INCREMENT.html</a> Great piece Mark, well written and argued. I&#8217;d go one step further and say that every database solves this problem in a different way, each of which is more efficient than using a table of sequences.
In MySQL, for instance, they have the auto_increment column. A side effect of this is some arguably not great database designs where every table has an artificial key even if it doesn&#8217;t require one. This is usually because the person designing the schema *knows* that the definition of a primary key column is and that every table needs one.
[1] http://dev.mysql.com/doc/mysql/en/example-AUTO_INCREMENT.html

]]>