The Case Against Coding for Portability - DATABASES ARE DIFFERENT

February 12, 2004

[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