Addresses should definitely have their own table.
Have you considered using Postgres? It allows for table inheritance in
much the same way that inheritance works in OOP. You could have a parent
table (like a parent class) for "People", and child tables (just like
child classes) for "Employee",
Addresses should definitely have their own table.
Have you considered using Postgres? It allows for table inheritance in
much the same way that inheritance works in OOP. You could have a parent
table (like a parent class) for "People", and child tables (just like
child classes) for "Employee", "
Hi Tony, Miguel
yes that was my intention at first, but to absorb all three, Shop,
Employee, and Customer (and there may be 2 more to come) into an Address
table would be inefficient both in storage space and search time,..no?
having this compound keys at a separate Address table is essential
actually, no, Shop, Employee, and Customer are not distinct.
in your instance they are the same type of entry.
don't distinguish them by tables, rather use a column to hold some sort
of an ID for each type.
of course you'll end up with a table with many columns, and many of
them will be null depe
Hi Miguel,
Thanks for the reply.
the non-customer is actually a Shop, so Employee, Customer and Shop are
distinct enough to have their own tables. Now they all have an Address, and
the problem is how do I allow multiple addresses for each these 'people'
(without using
a lookup table)
tony
The schema of your table is wrong, is you do bnormalize it you will find out
that you need two tables for this approach.
One table for your people and another one for the n addresses of your
people.
If you keep your current schema, you will have as many rows for one person
as many addresses for t
