I'm curious about what other folks are doing for db access.
Seems like PEAR is the "market leader" but that doesn't necessarily make it better than the others. I've seen a few posts that warn against PEAR and I would be interested in finding out why.
I've been using PEAR::DB for a while now and it seems to work pretty well but I'm always looking for improvements and wouldn't mind testing something new.
For the record - I use MySQL for smaller sites that sit on a shared server but for larger, more complicated sites I use PostgreSQL. (It has a few features that come in really handy on a larger project. Sub-selects comes to mind.) So having an abstraction layer becomes a necessity.
I'm not trying to start a holy war - just curious about what people are using and why they like it over the other options.
db abstraction layers? (PEAR::DB vs others)
Moderator: General Moderators
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
I usually write a simple data abstraction classes for connections and result record sets. This is usually no larger than 5k and faster than all the kitchen sink abstraction classes. If I need other features, like transactions, I can easily add them. Typically it's just:
connect
query
queryLimit
nextSequenceID
fetchRow
numRows
isError
getMessage
I usually don't need much more than that. On top of that I build data access objects like: queryUsers, getUserData, saveUserData, etc.
connect
query
queryLimit
nextSequenceID
fetchRow
numRows
isError
getMessage
I usually don't need much more than that. On top of that I build data access objects like: queryUsers, getUserData, saveUserData, etc.
I'm switching between MySQL and PostgreSQL pretty frequently. I often will build something useful for a larger client (using pgsql) that I want to use for other smaller clients that run on mysql.timvw wrote:How many times do you (or your customer) change between dbms in application lifetime? Is the inevitable overhead of the abstraction layer worth this?
For me, it's not so much how frequently is the client/app going to change - it's about reducing my overhead when I want to port from one to the other.
Although, I must admit that the more I use PostgreSQL the more I like it.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
I find that not only does the database change, but sometimes there is more than one type of database in a system. Having a standard interface makes the code much simpler to maintain.
I also often reuse code I have written for a different client with a different database. With an abstraction layer reuse is trivial. For example, how many different sets of user sign-in scripts do you want to have to maintain? Or pager code? Or form controllers?
I also often reuse code I have written for a different client with a different database. With an abstraction layer reuse is trivial. For example, how many different sets of user sign-in scripts do you want to have to maintain? Or pager code? Or form controllers?
-
timhortons
- Forum Commoner
- Posts: 29
- Joined: Thu Jan 15, 2004 11:48 am
- Location: Calgary, AB, Canada
I've been doing a bit of work with abstraction for accessing different types of databases, namely, MySQL and PostgreSQL
As of now, I've just settled on writing my own classes to deal with each database, and all i have to do to switch from mysql to postgre is change the connection/database information and file i include, queries stay the same, which is nice, now I dont have to re-write my code base and change each mysql_query to pg_query, etc.
I've heard about ADODB, it seems pretty cool, I dunno how popular it is, but it seems like something worth checking out if you need to have a standard for different types of databases.
ADODB Link: http://adodb.sourceforge.net/
As of yet, i haven't experimented with ADODB, but I think i will be in the near future. As of now, i've stuck to my own code classes because i'm only switching between mysql and postgre... and i've tailored them to how i have things setup in my databases, like table prefix's.
As of now, I've just settled on writing my own classes to deal with each database, and all i have to do to switch from mysql to postgre is change the connection/database information and file i include, queries stay the same, which is nice, now I dont have to re-write my code base and change each mysql_query to pg_query, etc.
I've heard about ADODB, it seems pretty cool, I dunno how popular it is, but it seems like something worth checking out if you need to have a standard for different types of databases.
ADODB Link: http://adodb.sourceforge.net/
As of yet, i haven't experimented with ADODB, but I think i will be in the near future. As of now, i've stuck to my own code classes because i'm only switching between mysql and postgre... and i've tailored them to how i have things setup in my databases, like table prefix's.
A discussion about Pear.
ADOdb is definitely worth looking at. There's also Eclipse 3.1 and EclipseCE.
For php5, Creole and Propel. ADOdb (I think) also supports php5. EclipseCE plans to support it.
I'm a fan of Eclipse mainly because it was my first experience of lean & mean classes - an epiphany moment when I was starting to learn about OOP. ADOdb is also very good. I haven't looked at Creole in detail. Pear is a bit of a failed project IMO.
ADOdb is definitely worth looking at. There's also Eclipse 3.1 and EclipseCE.
For php5, Creole and Propel. ADOdb (I think) also supports php5. EclipseCE plans to support it.
I'm a fan of Eclipse mainly because it was my first experience of lean & mean classes - an epiphany moment when I was starting to learn about OOP. ADOdb is also very good. I haven't looked at Creole in detail. Pear is a bit of a failed project IMO.