Database design: best approach

Question

I'm not a DBA and I don't know what is the best solution. I have two tables,

Custumers Table

CustomerId (primary key, identity)
...

and

Suppliers Table

SupplierId (primary key, identity)
...

and I want to store multiple telephone number and multiple emails. I thought to create two other tables, Emails and Telephones and use those in join with my Custumers and Suppliers, something like

Telephones Table

Id
UserId (reference to SuppliersId or CustomerId)
Value
...

But if I use as key for custumers and suppliers an Identity I'll have for sure problems. I'm thinking to do something like

Telephones Table

Id
SuppliersId
CustumersId
Value
...

But I don't know if is a good design. Any advice? Thank you

Answer 1

A good design would be

• Customers: Table of customers - CustomerId, Other columns
• Suppliers: Table of suppliers - SupplierId, Other columns
• Telephones: Table of telephones - TelephoneId, other columns
• CustomerTelephones: CustomerId, TelephoneId
• SupplierTelephones: SupplierId, TelephoneId

Answer 2

One idea:

Entity (ID (PK), {common fields})
Customer (ID (PK), EntityID (FK), {other fields})
Supplier (ID (PK), EntityID (FK), {other fields})
Telephone (ID (PK), EntityID (FK), Value)

This also has the added advantage of reducing duplication between Customer and Supplier.

Answer 3

我的建议是，您为表分配一个ID，然后添加具有与SupplierID和CustomerID相同数据类型的参考字段

Answer 4

you can do like

Customers: Table of customers - CustomerId, Other columns
Suppliers: Table of suppliers - SupplierId, Other columns
Telephones: Table of telephones - TelephoneId,TypeId,TypeName, other columns

where TypeName will be Customers or Suppliers , ant TypeId will be id of the resp.

Answer 5

The other answers are decent beginner solutions, but they all have the same fundamental flaw in that Customer or Supplier are Relationships and not their own unique entities. A Customer is not a person, it's a relationship between you and a person.

In fact a person could be an Employee, Customer, Supplier all at the same time, or over time.

A Customer or Supplier could also be a Business, with many involved people.

Here is the correct answer:

PARTY
id
type {individual, organization, automated_agent}
org_name null
first_name null
last_name null

PARTY_RELATIONSHIP
from_party_id FK PARTY
type {supplier_of, customer_of, ...}
to_party_id FK PARTY
from_date
to_date null

Usage:

Insert into party (id, type, org_name) values (1, 'organization', 'Raw Steel Co');
Insert into party (id, type, f_name, last_name) values (2, 'individual', 'Davide', 'X');

-- Raw Steel Co is both a customer of and supplier to you:
Insert into party_relationship values (1, 'supplier_of', 2, getdate(), null);
Insert into party_relationship values (1, 'customer_of', 2, getdate(), null);

Now, some people don't like Single Table Inheritance because of the nulls, but goddam it is easier to work with. Use Class Table Inheritance if you're finicky.

The 'type' columns should be foreign keys to type tables.