...which leads to inefficient SQL and poor system performance. This pattern results in code of the form:

$family->new_address($house_number,$postcode);

...

(...somewhere deep inside the family object...)
foreach my $person (@{$self->{members}) {
   $person->_new_address($house_number,$postcode);
}
[download]

Not the best example in the world, but I hope you get the general idea: the SQL that would normally be constucted with joins becomes decomposed and inefficient. And before anyone jumps up and down pointing out that they'd never implement code this way, I'll say this: most of the Monks that frequent and contribute to the Monestary are what I would consider to be (at least) above average programmers, in fact, Monks who've been here a while (even just lurking) would have picked up enough ideas, tips and tricks to stand head and shoulders above their cow-workers (or cow-students), and, indeed, would never implement decomposed SQL like the example, but if such object patterns are implemented, others will use them to write such decomposed database access. I know, I've seen it happen at almost every code shop I've ever worked in.

I don't believe that there is a definitive way around this problem, but if one considers the tables as the classes, the rows as objects and group the SQL according to the needs of business logic to create "aggregated" methods, there will be a much less scope for less able coders to write decomposed methods. I realise that's a lot of forethought before coding begins (sorry about that) but it pays off in the end when building scalable, performant systems.

rdfield