Re: Reasons for creating linking tables?
От | Jean-Yves F. Barbier |
---|---|
Тема | Re: Reasons for creating linking tables? |
Дата | |
Msg-id | 20101115133121.38f23b6b@anubis.defcon1 обсуждение исходный текст |
Ответ на | Reasons for creating linking tables? (Machiel Richards <machielr@rdc.co.za>) |
Список | pgsql-novice |
On Mon, 15 Nov 2010 14:11:12 +0200, Machiel Richards <machielr@rdc.co.za> wrote: Hi, > I would like to get the point of view from you guys out there who > has had a lot of database experience. > > While busy looking into a database that have a lot of issues I have > found the following scenario : > > - Let's call the 3 tables in question tables a,b & c. > - Currently table a has got a FK referencing table b > - table b contains only 1 field called id which is the PK and > also a FK referencing table c > - table c is once again a table with a couple of fields. > > > My question on this is, why create the linking table? > > Surely the linking table can be removed and the data referenced > directly between tables a & c? > > Is there a specific reason why this would need to be done? Think: invoice, RMA & credit note (and many other things) - if you avoid the b table you'll be obliged to put the reference in a &| c (obviously:) BUT they'll only be one time into a table. Now think to a not-so-often-but-existant case: you sell a product that fails, you issue an RMA to the customer and refund him making a credit note (or directly exchange the product) and ask your supplier to replace the product if you don't have table b, how will you get a back tracking from the new product to the old one? And you can even have a worse case: the new product can fail again, relaunching a whole "cycle". In short, tracking case like that *need* the b table to avoid Gordian knots to appear into your design (ie: you put 2 references in table a or c, but you have 3 failures.) JY -- Nothing succeeds like excess. -- Oscar Wilde
В списке pgsql-novice по дате отправления: