[Chicago-talk] modeling bridge tables

[Jay Strauss]

> "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.

So call the object "Lease" and the underlying table "CompanyBuilding" or
some such.  If you're going to use an RDBMS you've got to model it
correctly to store all the data.  If you want your objects named
something different than the underlying tables, so be it.

> 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.

You don't lose any info.  You can get to any column in any table (and
any intermediate tables) if there is a relationship(s) defined between
those tables.  That is, from building you can get the lease information,
and the company information, and visa versa.

Jay