Home Forums SQL Server 2005 Development Multiple references to same foreign table/column RE: Multiple references to same foreign table/column

  • The idea of a many-to-many table is that you have one ID for the row in one table, one ID for the row in another table, and a many-to-many table in between to connect the two.

    So, for example, you have your BASISREL table, with BRL_ID. Don't put any address data in there. You have your ADRES table, with ADR_ID in it.

    Instead of having multiple columns in BASISREL, have a table called something like BASISREL_ADR, with column BRL_ID and ADR_ID, possibly a TYPE column as well.

    If you have a customer address for someone, they have a record in BASISREL, and the address in ADRES, and in BASISREL_ADDRESS, you have the two IDs. If they have one type of address, the join table would have one row. If they have five types of addresses, they would have five rows.

    If you need to keep a TYPE column in that table, you can do so, to indicate that it's a customer address, or a delivery address, or a load address, etc.

    If you do it with multiple columns in the same table, what happens when someone in management suddenly discovers a need for another type of address, maybe an alternate contact address, or a summer vacation address? What do you do if someone decides that you need to keep a historical record, like "old billing address", "current billing address"? What happens if a type of address is no longer needed?

    In the multiple columns method, you have to add more columns to the table, modify all the code that queries/inserts/updates that table.

    In the many-to-many method, you just insert another row into the join table, and you're done. Inserting a row is much simpler than adding a column to a table.

    This also avoids the issue of having a wide table with lots of null columns. What if you end up with five types of addresses, so you have five columns, but most customers only have one or two of those types? The table will still take up disk space, have less rows per page, etc. That means slower IO, more cache used for less data, etc. Multiple rows has none of those drawbacks.

    That's my advice on the thing. You don't have to take it, but it's the best advice I can give you on this situation.

    - Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
    Property of The Thread

    "Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon