The Case Against Coding for Portability - DATABASES ARE DIFFERENT

Thursday Feb 12th 2004 by DatabaseJournal.com Staff
Share:

Ben Forta believes that when it comes to databases and SQL, coding for portability is a very bad thing indeed. Find out why in this article from ColdFusion Developer's Journal.

[From ColdFusion Developer's Journal]

Conventional wisdom dictates that code, all code, be written with portability in mind. After all, you wouldn't want to have to revisit and rewrite code when moving between platforms or environments, would you? And while I do believe that coding for portability is a good thing in general, I also believe that when it comes to databases and SQL, coding for portability is a very bad thing indeed.

Putting It in Context In the past few weeks I was involved in two long e-mail threads:

  • One involved a discussion about the generation of primary keys and the pros and cons of using identity (or auto-number) fields versus generating primary-key values from within ColdFusion. I argued that I did not want client code generating primary keys; that just does not make sense as each client would need to recreate that code.
  • The second involved the use of SQL implementation?specific features, useful functions, or stored procedures supported by a single DBMS only (in this case it was SQL Server). I explained that I did not want to have to jump through hoops to recreate functionality that my DBMS already offered; that would be a waste of my time, and a waste of runtime resources too.

The article continues at http://www.sys-con.com/coldfusion/article.cfm?id=705

Share:
Home
Mobile Site | Full Site
Copyright 2017 © QuinStreet Inc. All Rights Reserved