need design advice

we are desgning a db that will keep name and address information for all
kinds of entities: customers, employees, vendors, contacts, etc. Instead of
having N/A fields in each of the tables it seems like a good idea to have
one nameaddess table keyed by an identity int and have all of the other
tables reference this table via foreign key (either implicit or explicit).
What are the pros and cons of doing this kind of design?
Thanks,
T
Not sure what your referencing by an "N/A" field. However, if I'm
following you correctly, setting this up will depend if address can
have more than one entity (ie: one address can be a vendor and a
customer or something like that).
If not, then 2 tables should do it:
tbl_addresses
tbl_entities
the entities table will have "customers", "employees" etc. marked with
a PK (ie: "entity_id"). Then, of course, you'd have an "entity_id"
column in the addresses table that's a FK.
If an address can have more than one entity, then you can add a third
table that has three columns: the PK for the third table and 2 FK's
(one for addresses and one for entities). Here you wouldn't need the
FK in the "adresses" table.
So, let's say address #8 in the table has 1 entity and address #9 has
3, your 3rd table's data would something like:
ID ADDRESS_ID ENTITY_ID
1 8 2
2 9 2
3 9 4
4 9 5
and so on...
Of course, the "entity_id" shown above would refer to customers or
employees or whatever.
Hope that makes sense or helps in some way!
Jeremy

need design advice

we are desgning a db that will keep name and address information for all
kinds of entities: customers, employees, vendors, contacts, etc. Instead of
having N/A fields in each of the tables it seems like a good idea to have
one nameaddess table keyed by an identity int and have all of the other
tables reference this table via foreign key (either implicit or explicit).
What are the pros and cons of doing this kind of design?
Thanks,
TNot sure what your referencing by an "N/A" field. However, if I'm
following you correctly, setting this up will depend if address can
have more than one entity (ie: one address can be a vendor and a
customer or something like that).
If not, then 2 tables should do it:
tbl_addresses
tbl_entities
the entities table will have "customers", "employees" etc. marked with
a PK (ie: "entity_id"). Then, of course, you'd have an "entity_id"
column in the addresses table that's a FK.
If an address can have more than one entity, then you can add a third
table that has three columns: the PK for the third table and 2 FK's
(one for addresses and one for entities). Here you wouldn't need the
FK in the "adresses" table.
So, let's say address #8 in the table has 1 entity and address #9 has
3, your 3rd table's data would something like:
ID ADDRESS_ID ENTITY_ID
----
1 8 2
2 9 2
3 9 4
4 9 5
and so on...
Of course, the "entity_id" shown above would refer to customers or
employees or whatever.
Hope that makes sense or helps in some way!
Jeremysql

need design advice

we are desgning a db that will keep name and address information for all
kinds of entities: customers, employees, vendors, contacts, etc. Instead of
having N/A fields in each of the tables it seems like a good idea to have
one nameaddess table keyed by an identity int and have all of the other
tables reference this table via foreign key (either implicit or explicit).
What are the pros and cons of doing this kind of design?
Thanks,
TNot sure what your referencing by an "N/A" field. However, if I'm
following you correctly, setting this up will depend if address can
have more than one entity (ie: one address can be a vendor and a
customer or something like that).
If not, then 2 tables should do it:
tbl_addresses
tbl_entities
the entities table will have "customers", "employees" etc. marked with
a PK (ie: "entity_id"). Then, of course, you'd have an "entity_id"
column in the addresses table that's a FK.
If an address can have more than one entity, then you can add a third
table that has three columns: the PK for the third table and 2 FK's
(one for addresses and one for entities). Here you wouldn't need the
FK in the "adresses" table.
So, let's say address #8 in the table has 1 entity and address #9 has
3, your 3rd table's data would something like:
ID ADDRESS_ID ENTITY_ID
----
1 8 2
2 9 2
3 9 4
4 9 5
and so on...
Of course, the "entity_id" shown above would refer to customers or
employees or whatever.
Hope that makes sense or helps in some way!
Jeremy

Need a runtime processor license for SQL Server 2005

We are an ISV in the U.S. One of our customers, a United Nations agency located in Europe, urgently needs a runtime processor license for SQL Server 2005 Standard Edition. These licenses can be purchased only from companies that are members of the ISV Royalty Licensing Program, which we have not yet joined. Back in 2004, Microsoft accepted our company into its "Product Integration Program" (PIP), which was later discontinued and rolled into the ISV Royalty Licensing Program. The PIP allowed us to purchase SQL Server runtime licenses and sell them to our customers along with our off-the-shelf application.

The key differences between a runtime license and a "full-use" license are that a runtime license:
- costs less than half as much (US$1,758 vs. $4,876)
- can legally be used for only one application. Our customer is interested in SQL Server only to use it for our application, since they are not a SQL Server shop.

Are there any ISVs out there who are members of the ISV Royalty Licensing Program who would be interested in selling my customer a runtime processor license for SQL Server 2005? The cost from Microsoft is $1,758, but of course you would add your normal markup to that. We ourselves will not mark it up for this United Nations agency since we just want to give them what they need.

If interested, or if you can point me where to look for someone who might be, then please contact me at awad at auditleverage.com. Many thanks.
Mike

Hi,

I an not sure if that would comply with the licensing agreements, because AFAIK the customers can and is allowed only to use the database for their application, not for any other.

HTH, Jens Suessmeyer.

http://www.sqlserver2005.de