http://www.perlmonks.org?node_id=968574


in reply to Re^2: Search for ORM with Multi-Table-Object Support
in thread Search for ORM with Multi-Table-Object Support

DBIC is simpler than SQLAlchemy, so it doesn't do this kind of thing for you. Personally, I like the obvious separation of the objects: It makes the data model and relationships more apparent from the code (though I would remove the user_ prefix from the relationships). I've rarely had all of my code (DBIC or SQLAlchemy) survive database schema changes, unless I had planned for that schema to change (simple adding/removing optional columns for example).

Replies are listed 'Best First'.
Re^4: Search for ORM with Multi-Table-Object Support
by Xel (Novice) on May 03, 2012 at 07:10 UTC
    Personally, I like the obvious separation of the objects: It makes the data model and relationships more apparent from the code

    Sure - I'd have said something alike two years ago, too.

    But today I have to deal with a complex database structure, which is build out of at least 400 tables per Project-DB (with somewhat around 30 project DBs most of which have "nearly" identical structures) which has historically grown and is messy like hell. And it is my job to change that, make the database perform better, be more flexible and stuff - with nearly no man power to change the querys in the constantly growing and changing application.

    Starting with an ORM opens the door for constantly changing access from pure sql to an object oriented way and when this is done I wish to be able to change objects and database together without the need to let the app or the developers change the way they work. I belive this only to be possible if objects are not to closely linked to the data model and relations.

    So please understand that I have no room for "It's nicer if the objects line up nicely with the data-model"-Stuff. Yes it surely is, you are perfectly right, but I don't need it nice, I just need it working and changeable without to great effort.