Layering PHP Applications for other DBMS

views:

127

answers:

+2 Q:

Layering PHP Applications for other DBMS

I'm currently on my way to write a web application implementing the MVC and well reducing complex things. Yet I've been pondering for a few hours what to do for future database systems like Oracle, PostgreSQL, Firebird, etc.

Then again to implement these adapters in the logic is what gets me, should I just trigger-happy it with tons of SWITCHes? What can I do in this situation?

+2 A:

The typical answer to this is to use the ORM functionality in your framework. You can either treat your models as dataobjects or you could use some composition and let models have data objects. Either way, your data objects should be fairly abstract and mainly compile DB queries queries using methods - like the Zend framework does it with the Select object. This allows you to a) keep sql out of your objects and b) replace the objects that actually produce your sql.

So, if you data objects all inherit from the same base ORM class, this base class can be given a DB object that it sends queries to. If you swing it right, the ORM base class will be ignorant of the type of DB class: the data object compiles a select object and hands it over to the DB object that then interprets it in whichever way it finds best.

And the short answer: no, don't use a bunch of switch statements :)

Fake51 2009-07-04 22:45:24

I've been planning for a week to use Doctrine ORM (http://doctrine-project.org) because I didn't want to create a silly class wrapping up MySQL stuff. Yet I'm still a bit hesitant because ORM is still a new term for me. Will Doctrine ORM be the answer?

allenskd 2009-07-04 23:03:00

I have no idea about doctrine, never used it. However, using an ORM in general is a great step forward in code reuse and making your life easier in general. Using an established codebase for it is probably just better still, should hopefully come with a big bunch of Good Practices to learn from.

Fake51 2009-07-05 08:21:20

If you want a lightweight ORM for PHP, I'd look at Outlet. It should work with any standard PDO database type.

FilmJ 2009-07-04 23:56:11

+1 A:

Yet I've been pondering for a few hours what to do for future database systems like ...

You’re NOT gonna need it!

troelskn 2009-07-05 00:33:48

While that's a good thing to keep in mind, refactoring your app to be able to switch between major databases can be a massive pain if it was never designed with this in mind. DON'T swap the minor gain now for the massive pain later - do the tradeoff only if you're sure you can implement DB-switching as easily later as you can now.

Fake51 2009-07-05 08:25:15

When was the last time you had to change the database engine of an existing application? I must insist to disagree on your priority; I say, do the tradeoff only if you're positively sure (as in: have a concrete use case) that you need to switch database. There may be other, more valid, reasons for an abstraction to the database, but this is not one.

troelskn 2009-07-05 09:20:33

I'd like to share something and that is that I plan to open source the application I am writing. Of course it might seem way to early to even start thinking of providing other adapters. I believe the use of an ORM might be correct, but I guess time will speak eventually to see how it performs and if my decision was the right one. It's a great thing to keep in mind (the link you posted) to solve present problems and needs.

allenskd 2009-07-05 19:44:20

I would avoid ORM layers here is what Drupal developers have to say about

http://www.garfieldtech.com/blog/orm-vs-query-builders

Mariuz 2009-07-05 09:57:11

I would avoid Drupal

Fake51 2009-07-08 14:30:58

ansaurus

tags:

views:

answers:

Layering PHP Applications for other DBMS

related questions