[Chicago-talk] modeling bridge tables

[Wiggins d Anconia]

> Why complicate it?
> 
> If you can have a many to many as a common scenario, skip the local
storage of a
> 1->n (the building_id in company, in your example).
> 
> Use something like this:
> --------------------------
> 
> Company Table
> +----------------------+
> |  company_id          |
> |   ...others          |
> +----------------------+
> 
> 
> Building Table
> +----------------------+
> |  building_id         |
> |   ...others          |
> +----------------------+
> 
> 
> company_to_building table
> +----------------------+
> |  company_id          |
> |  building_id         |
> |   ...others          |
> +----------------------+
> 
> don't overcomplicate it.  From a company_to_building table, you have
access to
> the building and company objects without muddying their details and
> functionality.
> 
> -jason gessner
>     jason at multiply.org
> 

I agree with this, as great as OOP is, sometimes real world data can not
be effectively modeled in a strict practice without "breaking some of
the rules". If the relationship shows that one knows about the other and
vice versa than put in the circular references needed to achieve that,
just be careful with them.  But then I don't have all the design
pattern, etc. learning, I just solve real world problems ;-)...

http://danconia.org