It comes down to the classic DBA answer, it depends. I've primarily done work for internal applications, code that runs in-house for a company doing X. Platforms I've done that on include SQL Server, Sybase and Oracle. Never once did I seriously consider making my code portable on any of those projects. Why? Usually when I'm building something for a company, it's not a throw-away application. It's going to be there for 5-10 years. Why would I sacrifice the functionality that a CTE might bestow because the MS implementation of CTE's won't work on a Sybase database that I'm never going to be running this code on anyway? We were interviewing people for a position where I work and we were asking a few detailed questions about some query hints in SQL Server. The guy we were interviewing started chiding us for using unportable SQL code. End of interview. We're building SQL Server applications. We use SQL Server code and constructs. Period. To do otherwise is a disservice to the company I support and is just plain stupid.

On the other hand, I was working for a company that wanted to sell it's data. Because of that, we took as generic an approach as possible to our actual data structures. We went to town on our internal code, why not make our own apps performance scream? So, it was a business decision on the structures, not a technical one, but as usual, the technology had to support the business.

So, if I were working for a vendor that wanted to market to Unix platforms as well as Windows or WII or whatever, yeah, I'd go with the generic approach. Almost everywhere else, I'd focus hard on whatever platform I was working on in order to squeeze as much performance, scalability and functionality out of the apps as I could. I sure thought that was my job instead of blind adherence to some sort of dogma.