Professional Documents
Culture Documents
Database Design - Multiple Contact Information For Different Tables - Stack Ove
Database Design - Multiple Contact Information For Different Tables - Stack Ove
Products less. Build more. Use Stack Overflow for Teams at work to share knowledge with your colleagues. Free 30 day trial. Start your trial.
Search
Customers
Search…
PUBLIC
Ask Question
Log
StackinOverflow
Asked
Sign up
6 years, 3 months ago
Active
5 years, 9 months ago
Tags
Viewed
13k times
Users
Jobs
Blog
8
TEAMS
4
this?
What’s
I have a database with tables "person", "company", "shop", etc. Many of these tables must have "contact Ben Popper is the worst coder in the world:
information". The possibility to design this was asked in Database design - Similar Contact Information for Something awry with my array
Free 30 Day Trial
multiple entities
Now, in my database I leave a possibility to have a multiple addresses, multiple phones
and multiple emails to each contact data. This is my database schema: This week, #StackOverflowKnows fast planes,
math with dates, and code comments
Featured on Meta
By using our site, you acknowledge that you have read and understand our Cookie Policy, Privacy Policy, and our Terms of Service.
So, I make an intermediate table "contact" as a simplest way to link a "contact information" to each
table.
My question: is it a good practice to do this and to have a table with only one row? Linked
database database-design relational-database contacts
3
Database design - Similar Contact Information for
share improve this question multiple entities
edited May 23 '17 at 12:34 1
Customer/Company Address/Phone Numbers
Community ♦
1 1 Related
add a comment
280
Relational Database Design Patterns?
3 Answers active oldest votes
228
Schema for a multilanguage database
7
3
cities
id unsigned int(P) Database design best practices - linking/junction
state_id unsigned int(F states.id) table with multiple references
name varchar(50) // Omaha, Detroit, Tampa, etc.
Hot Network Questions
companies
id unsigned int(P)
How to select numerical sublists?
name varchar(75) // IBM, Microsoft, RedHat, etc.
... How does apt upgrade running programs?
id unsigned int(P)
name varchar(45) // Shop A, Shop B, etc. Is there a name for a chess variant where you are
... allowed to capture your own pieces?
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)
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.
Benny Hill
5,695 4 34 55
Ok, I see your point. You propose the same solution that here stackoverflow.com/questions/3636061/… (method 1). But
here a same disadvantage – "creation a lot of associative tables". There is another way to do this?
– nb.ag
Oct 28 '13 at
22:55
It's really not a disadvantage, normalization is a good thing. RDBMS's are good at joining tables as long as you index things
properly.
– Benny Hill
Oct 29 '13 at 0:01
I know this is 2 years old, but I'm wondering what your thoughts are for putting the email_type_id on each of the
XXXX_emails tables rather than putting it on the email table since every email will have a type. I'm designing something
similar and came to a similar design as you (with the exception of not breaking the phone number out into as many
columns), except that I was going to put the email_type_id on the email table.
– kralco626
Nov 20 '15 at 16:16
@kralco626 - two years later I would design this slightly differently. I would put the email_type_id in the emails table
as you suggest but I would also remove the id column from the shops_addresses , shops_contacts and
shops_emails tables. I would change their respective primary keys to be a composite of shop_id and address_id ;
shop_id and contact_id ; and shop_id and email_id .
– Benny Hill
Nov 20 '15 at 18:06
add a comment
My question: is it a good practice to do this and to have a table with only one row?
Not really. Looking at your diagram, I have to ask : can a contact really be linked to an arbitrary number of
persons ? If not, you should use 'person' as your parent table and make the other tables link to it.
share improve this answer
AurelienT
191 4
Actually yes, I can have a thousand persons, companies and shops. If I understand well your advice, I have to link directly
email, phone and address to all my entities (persons, companies, shops)? So I will have something like this: email ->
idemail, mail, idperson, idcompany, idshop Is it really better?
– nb.ag
Oct 28 '13 at 18:26
No, in your case you should in fact use associative tables as suggested by Benny Hill below. It is possible to do otherwise,
but insuring the data stays coherent would be really annoying and not worth it.
– AurelienT
Oct 29 '13 at 0:34
also link country to address not to city, as there may be cities in different countries and/or states/province/county that has
same name
– AquaAlex
Oct 16 '14 at 8:06
add a comment
Personaly, i don't like realy this method because we need to create any Entity for each table and a lot of
associative tables. I propose one table for contact informations and another one for addresses.
informations
- id INT
- name VARCHAR
- value VARCHAR
- type ENUM(phone, email, url, custom)
- idcompany INT NULL
- idcontact INT NULL
And
addresses
- id
- address1
- address2
- district
- postcode
- idcity
- idcompany
- idcontact
Youssef El Montaser
81 1 1 5
add a comment
Your Answer
Sign up or log in
Sign up using Google
Sign up using Facebook
Post as a guest
Name
Email
Required, but never shown
Post
Post Your
Your Answer
Answer
By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy
Not the answer you're looking for? Browse other questions tagged database database-design
STACK OVERFLOW
Questions
Jobs
Salary Calculator
Help
Mobile
Disable Responsiveness
PRODUCTS
Teams
Talent
Advertising
Enterprise
COMPANY
About
Press
Work Here
Legal
Privacy Policy
Contact Us
STACK EXCHANGE
NETWORK
Technology
Life / Arts
Culture / Recreation
Science
Other
Blog
Facebook
Twitter
LinkedIn
site design / logo © 2020 Stack Exchange Inc; user contributions licensed under cc by-sa 4.0
with attribution required.
rev 2020.2.15.36073