Re: Related Tables: Performance vs Elegance

Since a very low percentage of buildings have additional addresses, this might
be an alternative: Include the _primary_ address in the Building table; then
create a new table to contain supplementary address info.

Paul

-- 
------------------------------
Paul E. Kilmer
Hershey Foods Corporation
pkilmer_at_hersheys.com
http://www.hersheys.com
------------------------------



miguel wrote:


> 

> We have a table that holds information on Buildings (quite a large table

> and with lots of fields).  Normally each Building has one single street

> number associated with it, but in some situations it can have more than

> one.

> 

> Example:   Building XPTO,  1 - 3 - 5  (street numbers 1, 3 and 5)

> 

> Whe have a second table (Street_Number) wich holds one entry for each

> street number. In the above example the table would include 3 entries:

> 

>         XPTO    1

>         XPTO    3

>         XPTO    5

> 

> OUR QUESTION:

> 

> Since say, 90% of the Buildings only have one Street number, would it be

> more reasonable to include an extra field in the table Buildings, to hold

> the first street number, and another field to indicate if the number is/is

> not unique.   If the street number is not unique, then we would search the

> Street_Number table to obtain the remaining values.  This way the

> Street_Number table would include entries only for street numbers of 10% of

> the buildings.

> 

> Is this the correct way of doing it ?

> 

> The alternative would be to store all the street numbers for all buildings

> in the Street_Number table. When querying building information (including

> street number), searching the Street_Number table is therefore always

> mandatory...

> 

> Thank you in advance for any comments or tips,

> 

> Miguel