to pear DB or not to pear DB?

dugawug

i'm developing a small web app for a non-profit i'm affiliated with and i'm not sure if i want to use the pear DB abstraction layer or not. i've got a simple page currently developed w/o it, so all my database calls are using MySQL specific functions.
i know that using the pear DB is good if, say, we end up changing databases down the road, but i highly doubt we will. i mean, MySQL isn't going anywhere, right?
anyhow, i just simply don't like pear DB. maybe the fact that it took me a friggin hour to install it has something to do w/ that. also, i'm re-writing the simplest of code using DB functions and i'm having a hell of a time, probably b/c i have nothing but a cheesy pear manual to go by.
so i'm thinking to can this whole pear DB crap and go w/ MySQL specific functions. anyone have any advice on my predicament?

planetsim

Will this App be used by others? if so i dont not suggest it being used as some users will not have pear installed.

On the other hand, i have never used pear. And i dont plan on doing so just as i dont like relearning others code and how to use it (yes i now pear has a manual but reading the PHP manual is enough).

I made my own DB abstraction class, its probably not as good as Pear's but at least i know it works and i can keep using it in all the sites i create that require a DB abstraction class.

Shrike

Database abstraction is just good coding practice. Even if you don't change databases you might change how the functions operate and then it can save you alot of annoying recoding/restesting.

mrsocks

Shrike wrote:
Database abstraction is just good coding practice. Even if you don't change databases you might change how the functions operate and then it can save you alot of annoying recoding/restesting.

I know this is an old thread, but I am looking for kind of the same answers to dugawug's question. Why use pear::db ?

Shrike - can you be more specific with your answer? Why is using database abstraction just good coding practice if you know your application is not really going to grow or move? I can understand if the app has the potential to become large, but on many small sites, things dont really change. Also, if you are changing the way a function operates, how does using an abstraction layer help that? you will still need to change that function?

dugawug - did you or have you had more experience with pear and what ar eyour thoughts?

Thank you.

dugawug

well, i chose to go with PEAR DB as an abstraction layer, and like i figured, i haven't actually needed it so much at all yet, meaning i haven't switched away from using MySQL and probably won't for a long, long time.

otherwise, pear db is fine...a little tricky to install sometimes (i'm just a novice programmer) but the functions are similar to the standard php mysql stuff

have a go if you ever think you may switch databases in your app.
that and wait for someone experienced to reply 😉

Shrike

mrsocks wrote:
I know this is an old thread, but I am looking for kind of the same answers to dugawug's question. Why use pear::db ?

Shrike - can you be more specific with your answer? Why is using database abstraction just good coding practice if you know your application is not really going to grow or move? I can understand if the app has the potential to become large, but on many small sites, things dont really change. Also, if you are changing the way a function operates, how does using an abstraction layer help that? you will still need to change that function?

dugawug - did you or have you had more experience with pear and what ar eyour thoughts?

Thank you.

Imagine you have a function which performs a query and returns an array of data. Maybe you want the function to return a resource instead. It would be far easier to edit one function than to search through however many lines of code adjusting it as necessary.

justsomeone

Abstraction is good. It makes your code more portable. You may lose some database-specific functionality, but you gain database independance.

mysql may not go anywhere, but there may be a licencing change which causes you concern

or there might be a corporate change -"why support Oracle on this system and mysql over here? let's just use one database!"

another useful reason is to keep hackers guessing. if you can easily change which database you use every month or two, then it makes it more difficult for anyone trying to break into your system to hunt you down

But, as with most things in life, go with what makes sense for you.