June 21, 2012 at 7:26 am
Like Oracle on Windows vs. UNIX. Oracle is a pig on Windows.
Cheers
June 21, 2012 at 7:31 am
cfradenburg (6/21/2012)
Grant Fritchey (6/21/2012)
There is a very real, and evidently apparent in more than just the SQL sphere, understanding that you can design for performance on a platform, or you can design for portability between platforms, but you can't really design for both (without forking your code, readily acknowledged there, but that reinforces the point, not negates it).And if you can provide an example of a large DB designed for portability that performs well on multiple platforms I would love to see it. Because if there's a way to design for portability and have it perform well there's no reason not to do that.
I've worked with at least two that I know of, they apparently perform well enough to sell and use. I'm sure that portability exacted a cost, so my interest is that despite these costs, the vendor felt it was worth it, so there really is this concern out there. One thing to note is that these were application vendors where the business processing did happen in application code.
Additionally its worth mentioning that there is an SQL standards effort, with several published standards.
And relational design theory is itself portable.
I freely admit that I'd like to be biased toward portability in the general case, but that it would take additional effort to materialize that bias in specific efforts.
June 21, 2012 at 7:45 am
If you want to achieve application portablity and performance, you need to design for it, and such design usually requires two separate code bases. You need to separate the Data Access Layer from the Application Layer. The biggest differences are in how each database systems stores, retieves, and manipulates data. How the application works with data should be database agnostic.
If you isolate the access to the database you can port your application to a different RDBMS by writing a DAL specifically for that system. The actual application should not have to change.
June 21, 2012 at 7:57 am
patrickmcginnis59 (6/21/2012)
I freely admit that I'd like to be biased toward portability in the general case, but that it would take additional effort to materialize that bias in specific efforts.
I think that's the general case: who in their right mind is going to be against portability if that additional effort is low enough? Nobody. However there is a point at which the additional cost of making something portable is outweighed by the costs of the sacrifices you have to make to do so, as multiple posters upstream have noted.
Relational databases are already the red-headed stepchild of the application development world. There aren't that many developers (or even application architects) who truly understand relational databases. In the SQL Server world, I will point to the raging misuse of (NOLOCK) as evidence of this (in DB2 it is WITH UR).
To allow such people to design 'portable' applications is just asking for trouble. Early in my career I worked on just such an application, and it was a complete disaster that drove the company into bankruptcy.
June 21, 2012 at 8:22 am
Dean Cochrane (6/21/2012)
patrickmcginnis59 (6/21/2012)
I freely admit that I'd like to be biased toward portability in the general case, but that it would take additional effort to materialize that bias in specific efforts.I think that's the general case: who in their right mind is going to be against portability if that additional effort is low enough? Nobody. However there is a point at which the additional cost of making something portable is outweighed by the costs of the sacrifices you have to make to do so, as multiple posters upstream have noted.
I can agree with that. Its about judging the costs and benefits of portability.
Relational databases are already the red-headed stepchild of the application development world. There aren't that many developers (or even application architects) who truly understand relational databases. In the SQL Server world, I will point to the raging misuse of (NOLOCK) as evidence of this (in DB2 it is WITH UR).
True, but I would like to offer a seperation of concerns here, for instance, (I believe) you can develop an application with persistance that has absolutely no relational technology at all that can still be an objectively correct design, but a race condition is still objectively a race condition no matter what technology you're using.
Viewing 5 posts - 61 through 64 (of 64 total)
You must be logged in to reply to this topic. Login to reply