Even if you've no plans to, be able to is a useful discipline and keeps your code clean. For years I worked on a Solaris project that we also maintained a build for that no-one used on NT. But when a customer wanted an AIX version, it took as long to produce one as it did to find an AIX box to compile it on.

Same is true of databases. There are things that people don't even think about if they've only ever used one database. What's your DB's lock escalation strategy? Are cursors cheap or expensive? What kinds of indexes don't you have, and could any of them ever be useful? And so on...

You'll remember this when someone is suddenly interested in your project and waving wads of cash at you, but it must run on SQL Server, today.

Are you kidding me? It does happen occasionally. I'm guessing you haven't been a developer for very long if you've never run into this. The fact that abstraction libraries and ORMs exist in the first place suggests that it's a real problem.

My comment was based on my own experience having to move a PHP app from SQL Server to Oracle. And it was just about the last app I'd ever expect to have to move from one database to another.

I'm not sure why my original comment was modded down because it's just plain common sense. With all the libraries out there for abstracting database access and ORMs you're just begging for trouble if you still use the database specific stuff. Unfortunately, in my case none of that stuff was available yet.

That's a good point. In 10 years I've only had to do that once.

Still, I like using an abstraction layer because they tend to hide the quirks of the particular database - I use MySQL, Postgres and SQLite all fairly often, and by using PHP's PDO I can not worry about the differences as much as if I were using the database-specific drivers.