[dba-SQLServer] 2 Questions -- one about terminology, one about design choices

On 11 Aug 2004 at 17:43, Arthur Fuller wrote:

> 
> So back to the two (or more models): 
> 
> A) Jam all possible fields into a single OrderDetails table, mask the
> irrelevant ones using queries, and lose a lot of the built-in validation
> stuff that Access offers.
> 
I don't like it.  Wastes a lot of space, can run into maximumn fields in 
table problems, and worst fo all - what happens when you  have one set of 
flight details, two sets of hotel details, three sets of concert details 
all on the same order?

> B) Place all the stuff common to all DetailTypes in a single
> OrderDetails table, which also contains a pointer to the N tables
> corresponding to the collection of DetailTypes. Show only the common
> fields in the subform; provide an Edit button or double-click or
> whatever that opens the form corresponding to these fields unique to
> each DetailType.
> 

That's the way I'd go. Although I'd probably end up going for a series of 
details tabs rather than separate forms.

Probably all I'd store in the link table is the OrderPK, Type and 
DetailTablesPK.

> 
> In this model, there is a term that describes the OrderDetails table,
> whose basic function is to bridge the gap between Orders and the various
> tables corresponding to the DetailTypes. Anyone know what this term is?
> 

I've always just called it a link table.
-- 
Stuart