3 ms·

You will regret that decision when you have to move your app to a different database. The only reason that PDO, ADO, etc. stuff exists is because the built-in d

by jm4 18y ago

You will regret that decision when you have to move your app to a different database. The only reason that PDO, ADO, etc. stuff exists is because the built-in database functions are platform-specific and totally inconsistent with one another.

dabeeeenster 18y ago
Why do people always assume that you will move your application to a different DBMS at some point?
- compay 18y ago
  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.
- cosmo7 18y ago
  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.
- gaius 18y ago
  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...
- jm4 18y ago
  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.
alex_c 18y ago
I am aware that I might regret that decision IF I have to move my app to a different database. Even so, I don't think such a move would be that painful. I've taken great care to isolate all SQL queries from the rest of the code, and to keep them all in one place. I also have queries which I've had to optimize for the specific database I'm using (MySQL). I doubt an out-of-the-box DAL would be able to help with those in the current incarnation, or eliminate the need to rewrite them if the database changes. The biggest challenge I can foresee is if they grow to the point where I need multiple databases in order to scale. I don't have enough experience yet to know whether existing frameworks would help in such a scenario, or just get in the way. But changing from MySQL to PostgreSQL? I'm fairly confident I can live with that. But first and foremost, they're small-to-medium projects (in terms of code size), with relatively simple data models, and a single developer. I wouldn't advocate this approach for large projects.
- jm4 18y ago
  The problem with moving to a different database when you've used the database specific functions in PHP is that you have to use completely different functions for the new database. Moving from MySQL to PostgreSQL isn't so bad because those functions are fairly consistent. I think in most cases you just change mysql_ to pg_. Moving to something like Oracle or ODBC is a major task. You end up having to rewrite quite a bit of code even if you've isolated your queries. I had to learn this the hard way through experience and thought I'd share so someone else could avoid the hassle. The app that I had to move was very small and about the last thing I thought I'd have to spend much time maintaining. Six months later I was wasting half a day rewriting database code. Not sure why I would get modded down for this.

by jm4 18y ago

dabeeeenster 18y ago

Why do people always assume that you will move your application to a different DBMS at some point?

compay 18y ago
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.
cosmo7 18y ago
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.
gaius 18y ago
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...
jm4 18y ago
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.

alex_c 18y ago

I am aware that I might regret that decision IF I have to move my app to a different database. Even so, I don't think such a move would be that painful. I've taken great care to isolate all SQL queries from the rest of the code, and to keep them all in one place. I also have queries which I've had to optimize for the specific database I'm using (MySQL). I doubt an out-of-the-box DAL would be able to help with those in the current incarnation, or eliminate the need to rewrite them if the database changes. The biggest challenge I can foresee is if they grow to the point where I need multiple databases in order to scale. I don't have enough experience yet to know whether existing frameworks would help in such a scenario, or just get in the way. But changing from MySQL to PostgreSQL? I'm fairly confident I can live with that. But first and foremost, they're small-to-medium projects (in terms of code size), with relatively simple data models, and a single developer. I wouldn't advocate this approach for large projects.

jm4 18y ago
The problem with moving to a different database when you've used the database specific functions in PHP is that you have to use completely different functions for the new database. Moving from MySQL to PostgreSQL isn't so bad because those functions are fairly consistent. I think in most cases you just change mysql_ to pg_. Moving to something like Oracle or ODBC is a major task. You end up having to rewrite quite a bit of code even if you've isolated your queries. I had to learn this the hard way through experience and thought I'd share so someone else could avoid the hassle. The app that I had to move was very small and about the last thing I thought I'd have to spend much time maintaining. Six months later I was wasting half a day rewriting database code. Not sure why I would get modded down for this.