views:

301

answers:

3

Hello, guys. Need your advice very much.

We'are working on the PHP project, which was in development for 2+ years, and now the team is ready and feel willingness to switch the development on ORM rails. Because it realy fasts the development and allow you to operate by Objects and not think in terms of SQL code and database tables in most times.

We have decided to choose Doctrine ORM, because it has YAML data fixtures load - we need it very much for our unit-tests.

The main fear I have, is that using of new ORM framework can slows the site's performance. We can't make a shared connection between current DB abstraction layer(which uses pg_connect syntax, not PDO-compatible). DB connection mechanism can't be switched to PDO-compatible, because there are lots of SQL code incompatible with PDO_SQLITE syntax.

So, as I understand if we will start using it, it will double our DB connections. I'm not sure DB server will be able to handle this.

What would you recommend us to do in this circumstances? Thanks, in advance Regards

+1  A: 

Of what relevance is PDO_SQLITE?

Unless you actually plan on using the Sqlite driver then compatibility is not mandated by PDO.

If you aren't going to use Sqlite then I would make the legacy DB layer PDO compatible and re-use the connections until you can fully migrate to doctrine.

That said, the level of connections is not going to be your only performance concern moving to an ORM. They are inherantly inefficient so I'd expect slower queries, higher bandwidth use between application servers and the database servers and higher memory use at the application level due to redundant data inevitably getting selected. Depending on your current setup, the above may or may not be issues.

You should probably take that last paragraph with a pinch of salt though because they are just traits of ORMs in general and not doctrine in particular, with which I've had no experience.

Mike
A: 

The obvious thing you can do is not open a database connection until you need it. I personally use code like this:

public function connect() {
  if (!defined('CONNECT')) {
    mysql_connect(...);
  }
}

public function db_query($query) {
  connect();
  $ret = mysql_query($query);
  if (!$ret) {
    die(mysql_error());
    error_log(mysql_error() . ' - ' . $query);
  }
  return $ret;
}

to reduce the amount of repetitive and to only open a connection when you need one.

In your case you then need to break off the smallest chunk you can to begin with. Ideally it should be a vertical slice, meaning this slice will do almost all of its database work with the new code and very little with the old. This way you can minimal doubling up of database connections and this lets you build up some skills and get some experience too.

Beware though, ORM is not by any means a panacea. You may hate SQL and find it fiddly and error prone but you are, for the most part, simply trading one set of problems for another. I personally think that while ORM can be useful it has been overhyped and is more of a false economy than many either realize or are willing to admit. I wrote more on this in Using an ORM or plain SQL?

I'm not saying you shouldn't do it. Just don't go in thinking it'll solve all your problems. Also, since this rewrite won't actually change the functionality at all (from what you've described) I'm not sure if the cost of doing so compares favourably with fixing what's there already. Too many unknowns to say which way your situation will go.

cletus
A: 

Well, yes and no – your DB connections will only be doubled as long as you have both a non-PDO and a PDO connection.

I'm not sure what you mean with the PDO_SQLITE reference, since SQLite is a wholly different database than the PostgreSQL it seems you're using now.

You should be able to run your current queries through PDO::query just as you do today unless you are doing something very wrong :)

mikl