[Chicago-talk] modeling bridge tables

[Jim Thomason]

> I'd think you could use Class::DBI pretty easily for this.  It gives you
> all the methods for traversing the relationships.  If you have to do
> custom sql (for big joins for example) it has a facility for that too.
> 
> Ps just call them
> 
> Company---CompanyBuilding---Building

"CompanyBuilding" doesn't make any more sense. It's not an object, it
doesn't model anything in the real world, it's an object
representation of an abstract concept. I can get a little better by
re-defining my terms, say by calling this middle object a "lease" or a
"BuildingAgreement" or something like that. Disadvantages to this
include
1) the bridge table may already exist, giving the object and the table
completely different names. Minor point, but still a little annoying.
2) The concept isn't universal, you can't always re-define the bridge
table into something logical that makes sense as an object.

Regardless, looking into Class::DBI and its limitations is what got me
motivated to post this anyway. I still need to use the CompanyBuilding
object when using Class::DBI. The best I can do is to use its magical
methods to map the CompanyBuilding object into a Company object (or
Building, as appropriate), but then again I still lose the information
in the bridge table.

-Jim....