[CDBI] Why does CDBI not populate the object on insert
moseley at hank.org
Fri Mar 6 04:46:13 GMT 2009
On Thu, Mar 05, 2009 at 04:10:10PM -0800, Michael G Schwern wrote:
> And then you have data normalization at the database level rather than the
> application level. Capitalization, phone numbers, credit card numbers,
> province names, country names... all are better done in the database than in
> individual applications to keep data integrity.
I'm a huge fan of very tight constraints and data checking in the
database -- in my view the database is really the application and the
constraints must keep it in a stable state. But, I can't think of any
place where I use a trip to the database and back for normalization.
I suspect if I thought about it a while I could find an exception to
that, but it it would be very rare in my case.
> Honestly, lazy loading is probably the biggest architectural mistake I made in
> CDBI. It seemed like a good idea at the time in 1999, with limited memory and
> I was working on a message storage system (lots of small headers, big body)
> but honestly it made the code way more complicated than it should be and
> probably drags performance down more than it speeds up. I should have just
> made each message join from header and body tables but that would have
> required good join support early on and I suck at joins.
Is the lazy loading expensive when not used? That is where Essential
is tuned for the columns used?
> > $country = $hood->city->state->country;
> Speaking of sucking at joins, that's always going to suck in CDBI.
Sure, normally that would be very slow, which is what caught my
attention. But, in this specific case I had created $state, from
$counry, and $city from $state, and so on, so all the related objects
were around. There's was no real reason to go back to the database
(except for reasons discussed today).
> Consider using Class::DBI::Sweet or DBIx::Class both of which I
> believe can model the above as a join instead of a string of
One of the reasons I still like CDBI is that it's a pretty
simple ORM, and when I need more complex joins (which is very common
in anything but the simplest application) I use set_sql(). I find SQL
a nice clean way to write database queries. ;)
moseley at hank.org
Sent from my iMutt
More information about the ClassDBI