"Keith Eckhardt" <keitheckhardt@[EMAIL PROTECTED]
> wrote in message
news:d7idnenlRMtsr83anZ2dnUVZ_tmhnZ2d@[EMAIL PROTECTED]
>I am looking at a new database design for the association I belong to.
In
>particular I am looking at how to handle telephones, addresses, and
email.
>All of these could have zero to as many as five values for any of the
>entities. Our society has the following entities with examples of
address
>types following.
>
> Society (Site, Mailing, Billing, Contact)
> District (Contact, Mailing, Secretary)
> Region (Contact, Mailing)
> Chapters (Contact, Mailing, Billing,Meeting)
> Members (Home, Business, Althome)
>
> Every entity has a globally unique numeric ID. I am looking at an
address
> table with the following columns.
>
> EntityID, Address1,Address2,Address3,City, State,Zip,Country,AddressType
>
> I am doing the same thing for telephone and email address. As a
webmaster
> I have three email addresses I want to expose.
>
> The old design has a single table per entity with a very wide record.
> There are two sets of addresses possible, three telephones, and three
> emails. Most of the columns have little data in them.
>
> I've gotten some comments that I have too many tables and performance
will
> suffer. From the design literature I think I am headed in the right
> direction.
>
> Comments?
>
I don't think you have too many tables. What program language and
database
will be used for the back-end solution?
I have seen it where the phone itself was a table that had multiple
records
for a EnityID based on phone type.
|
