0

Consider the following READ and WRITE queries:

Read

// Retrieves a person (and their active game score if they have one)
$sql = "SELECT CONCAT(people.first_name,' ',people.last_name) as 'name',
               people.uniform as 'people.uniform',
               games.score as 'games.score'
        FROM my_people as people
        LEFT JOIN my_games as games ON(games.person_id = people.id AND games.active = 1)
        WHERE people.id = :id";
$results = DB::select(DB::raw($sql),array("id"=>$id));

Write

 // Saves a person
 $person = new People;
 $person->data = array('first_name'=>$input['first_name'],
                       'last_name'=>$input['last_name'],
                       'uniform'=>$input['uniform']);
 $personID = $person->save();

 // Save the game score
 $game = new Games;
 $game->data = array('person_id'=>$personID,
                     'active'=>$input['active'],
                     'score'=>$input['score']);
 $game->save();
  • I put every write (INSERT/UPDATE) operation into my own centralized repository classes and call them using class->methods as shown above.
  • I may decide to put some of the read queries into repository classes if I find myself using a query over and over (DRY). I have to be careful of this, because I tend to go back and adjust the read query slightly to get more or less data out in specific areas of my application.
  • Many of my read queries are dynamic queries (coming from datagrids that are filterable and sortable).
  • The read queries will commonly have complex things like SUMs, COUNTs, ORDERing, GROUPing, COMPOSITE keys, etc.

Since my reads are so diverse, why would I need to further abstract them into Laravel's Eloquent ORM (or any ORM), especially since I'm using PDO (which has 12 different database drivers)? The only advantage I can see at the moment is if I wanted to rename a database field then that would be easier to do using the ORM. I'm not willing to pay the price in greater abstraction/obscurity for that though.

prograhammer
  • 20,132
  • 13
  • 91
  • 118
  • I've just finished a chunk of work on a PDO/SQL project and moved onto a complex PDO/Propel project. Now I've moved I'd forgotten how easy an ORM makes things, mainly due to auto-complete. My dev flow and velocity just feels better. Abstracting away SQL/connections/prepare etc is nice as well. If your queries are frequently complex then you might not benefit, but most projects will be able to do things "the ORM way" 90% of the time, and the remainder can be done in SQL. ORMs often help with migrations too. – halfer Jan 20 '15 at 18:16
  • 1
    I don't know whether Eloquent offers these advantages - but I am in favour of ORMs in general. I don't think you have to use them. You may find that Laravel encourages it - some frameworks assume you use the bundled ORM, and it can be a pain if you don't. I'll leave that for a Laravel user to answer. – halfer Jan 20 '15 at 18:18
  • You're right in that it's nice in abstracting away the "connections" and "prepare" stuff (Laravel does this). But that is not the issue. I'd still be passing in a big SQL string. Regarding migrations, again I can write those into a migrations file in Laravel (so still doesn't apply to needing the ORM). – prograhammer Jan 20 '15 at 18:23
  • How often will you be passing in a SQL string? In my project, it's 5% of the time, probably less. If it is more than (say) half for you, it may not be worth it. It depends on whether you want to use any ORM features too, I guess - Propel offers various behaviours like table inheritance, versioning and nested set implementations - all better than writing them myself. Ultimately it sounds like you are against using an ORM, which may drag down your productivity if you "force" yourself to. If so, don't use it. – halfer Jan 20 '15 at 18:28
  • 1
    [Points for/against using ORMs in general](http://stackoverflow.com/questions/7765070/redbean-orm-performance). – halfer Jan 20 '15 at 18:32
  • 1
    Laravel lets me use the benefits of "connections/prepares/migrations" and still pass in raw SELECT queries. However, if I use it for the query as well, then it becomes unnecessarily abstracted. It's easier for me to think in SQL. It's not like it takes me lots of time to write a query either. The tables are created in a sensible manner. The ORM typically will do additional unnecessary queries (like a query to get the record before doing any other work) or do inefficient things like include * all fields in the select. Thanks for your commits here! – prograhammer Jan 20 '15 at 18:41
  • Alright, there's your answer `:-)`. – halfer Jan 20 '15 at 18:43

0 Answers0