2013-10-28 17 views
6

Tôi có một cơ sở dữ liệu với bảng "người", "công ty", "cửa hàng", v.v. Nhiều bảng này phải có "thông tin liên hệ". Khả năng thiết kế này được yêu cầu trong Database design - Similar Contact Information for multiple entities Bây giờ, trong cơ sở dữ liệu của tôi Tôi để lại khả năng có nhiều địa chỉ, nhiều điện thoại và nhiều email cho mỗi dữ liệu liên lạc. Đây là sơ đồ cơ sở dữ liệu của tôi:Thiết kế cơ sở dữ liệu - Nhiều "Thông tin liên hệ" cho các bảng khác nhau

database contact information

Vì vậy, tôi thực hiện một bảng trung gian "liên hệ" như là một cách đơn giản nhất để liên kết một "thông tin liên lạc" để mỗi bảng.
Câu hỏi của tôi: thực tiễn tốt để làm điều này và có một bảng chỉ có một hàng?

Trả lời

3

Câu hỏi của tôi: thực tiễn tốt để làm điều này và có bảng chỉ có một hàng?

Không thực sự. Nhìn vào sơ đồ của bạn, tôi phải hỏi: một người liên hệ có thực sự được liên kết với một số người tùy ý không? Nếu không, bạn nên sử dụng 'person' làm bảng cha của bạn và làm cho các bảng khác liên kết với nó.

+0

Trên thực tế có, tôi có thể có một ngàn người, các công ty và cửa hàng. Nếu tôi hiểu rõ lời khuyên của bạn, tôi phải liên kết trực tiếp email, điện thoại và địa chỉ với tất cả các thực thể của tôi (người, công ty, cửa hàng)? Vì vậy, tôi sẽ có một cái gì đó như thế này: 'email -> idemail, mail, idperson, idcompany, idshop' Có thực sự tốt hơn? –

+1

Không, trong trường hợp của bạn, bạn nên sử dụng bảng kết hợp như đề xuất của Benny Hill bên dưới. Có thể làm khác, nhưng đảm bảo dữ liệu vẫn mạch lạc sẽ thực sự gây phiền nhiễu và không đáng giá. – AurelienT

+0

cũng liên kết quốc gia để giải quyết không thành phố, vì có thể có các thành phố ở các quốc gia và/hoặc tiểu bang/tỉnh/hạt có cùng tên – AquaAlex

7

Đây là cách tôi sẽ thiết kế cơ sở dữ liệu của bạn:

address_types 
    id    unsigned int(P) 
    description  varchar(10) // Mailing, Physical, etc. 

addresses 
    id    unsigned int(P) 
    line1   varchar(50) // 123 Main Street, etc. 
    line2   varchar(50) // Default NULL 
    city_id   unsigned int(F cities.id) 
    zip    varchar(6) // 12345, A1A 1A1, etc. 
    zip4   char(4) // Default NULL 
    lat    decimal(10,8) // 13.12345678, etc. 
    lon    decimal(11,8) // 110.12345678, etc. 

cities 
    id    unsigned int(P) 
    state_id  unsigned int(F states.id) 
    name   varchar(50) // Omaha, Detroit, Tampa, etc. 

companies 
    id    unsigned int(P) 
    name   varchar(75) // IBM, Microsoft, RedHat, etc. 
    ... 

companies_addresses 
    id     unsigned int(P) 
    company_id   unsigned int(F companies.id) 
    address_id   unsigned int(F addresses.id) 
    address_type_id  unsigned int(F address_types.id) 

companies_contacts 
    id     unsigned int(P) 
    company_id   unsigned int(F companies.id) 
    contact_id   unsigned int(F contacts.id) 
    contact_type_id  unsigned int(F contact_types.id) 

companies_emails 
    id     unsigned int(P) 
    company_id   unsigned int(F companies.id) 
    email_id   unsigned int(F emails.id) 
    email_type_id  unsigned int(F email_types.id) 

contact_types 
    id    unsigned int(P) 
    description  varchar(10) // Home phone, Mobile phone, FAX, etc. 

Trong số điện thoại Bắc Mỹ giống như thế này: CC-AAA-EEE-SSSS-XXXXXXX nơi CC là mã quốc gia, AAA là mã vùng , EEE là trao đổi, SSSS là trạm và XXXXX là phần mở rộng.

contacts 
    id    unsigned int(P) 
    country_code varchar(3) 
    area_code  varchar(3) 
    exchange  varchar(3) 
    station   varchar(4) 
    extension  varchar(10) // Default NULL 

Xem ISO 3166-1.

countries 
    id    char(2) // ca, mx, us, etc. 
    iso3   char(3) // can, mex, usa, etc. 
    iso_num   char(3) 
    name   varchar(44) // Canada, Mexico, United States, etc. 

email_types 
    id    unsigned int(P) 
    description  varchar(10) // Personal, Work, etc. 

emails 
    id    unsigned int(P) 
    address   varchar(255) // [email protected], etc. 

shops 
    id    unsigned int(P) 
    name   varchar(45) // Shop A, Shop B, etc. 
    ... 

shops_addresses 
    id     unsigned int(P) 
    shop_id    unsigned int(F shops.id) 
    address_id   unsigned int(F addresses.id) 
    address_type_id  unsigned int(F address_types.id) 

shops_contacts 
    id     unsigned int(P) 
    shop_id    unsigned int(F shops.id) 
    contact_id   unsigned int(F contacts.id) 
    contact_type_id  unsigned int(F contact_types.id) 

shops_emails 
    id      unsigned int(P) 
    shop_id     unsigned int(F shops.id) 
    email_id    unsigned int(F emails.id) 
    email_type_id   unsigned int(F email_types.id) 

Xem ISO 3166-2.

states 
    id    unsigned int(P) 
    country_id  char(2)(F countries.id) 
    code   varchar(2) // AL, NF, NL, etc. 
    name   varchar(50) // Alabama, Newfoundland, Nuevo León, etc. 
+0

Ok, tôi thấy quan điểm của bạn. Bạn đề xuất cùng một giải pháp ở đây http://stackoverflow.com/questions/3636061/database-design-similar-contact-information-for-multiple-entities (phương pháp 1). Nhưng ở đây một bất lợi tương tự - "tạo ra rất nhiều bảng kết hợp". Có một cách khác để làm điều này? –

+2

Nó thực sự không phải là một bất lợi, bình thường hóa là một điều tốt.RDBMS là tốt tại tham gia các bảng miễn là bạn chỉ mục những điều đúng. –

+0

Tôi biết đây là 2 năm, nhưng tôi tự hỏi suy nghĩ của bạn là gì khi đặt 'email_type_id' trên mỗi bảng' XXXX_emails' thay vì đặt nó trên bảng 'email' vì mọi email đều có một loại. Tôi đang thiết kế một cái gì đó tương tự và đến một thiết kế tương tự như bạn (với ngoại lệ không phá vỡ số điện thoại ra thành nhiều cột), ngoại trừ việc tôi sẽ đặt email_type_id trên bảng email. – kralco626

2

Cá nhân, tôi không thích tạo ra thực thể này vì chúng ta cần tạo bất kỳ Thực thể nào cho mỗi bảng và nhiều bảng liên kết. Tôi đề xuất một bảng cho thông tin liên lạc và một bảng khác cho địa chỉ.

informations 
- id INT 
- name VARCHAR 
- value VARCHAR 
- type ENUM(phone, email, url, custom) 
- idcompany INT NULL 
- idcontact INT NULL 

addresses 
- id 
- address1 
- address2 
- district 
- postcode 
- idcity 
- idcompany 
- idcontact 
Các vấn đề liên quan