I am new to modeling and creating these relational databases, so any recommended reading would be great after reading what I am trying to do.
I am creating a table for contacts. There is currently these tables:
vendors,
primarycontacts
the columns in primary contacts look like this:
table contacts: id, name, vendor, phone
Now sometimes, a contact has multiple phones (Cell, office, home, skype, etc..) so I was thinking of making another table "Phone" with columns: ID, Name, and Phone.
Also, some contacts may share the same phone number.
This would be a many to many relationship, am I right. Many contacts sharing phone numbers that all work for the same vendors or different vendors. W
Would it be good to do this (Seperate phone numbers table), instead of having Ph1, Ph2, Ph3 column in contacts? What if there are more numbers? And what if there is only one phone number? This would be wasted space. Should I only have ID and phone_number in the phones table, or also have ID, Phone_Number, and Phone_Name?
It depends on your project but the idea of many to many does not make sense when it is private info. Think about what happens when someone edits a phone number. Now all other users using that one have changed info, even if they don't want to and are not aware of.
Try something like:
table phones: id, contact_id, phone
table contacts id, user_id, firstname, lastname etc.
Would it be good to do this (Seperate phone numbers table), instead of
having Ph1, Ph2, Ph3 column in contacts?
Yes, you will want to create a separate "PhoneNumbers" table. You can then remove the "phone" field from "Contacts" all together.
Your "PhoneNumbers" table is going to have two fields: contacts_id and phone_number (as a concatenated key). This will enable your design to be flexible enough to allow contacts to have multiple phone numbers.
You can do a many to many relationship but as Bryce says you need to be aware that changes to phone number may affect more than one contact. If you can guarantee you are only doing inserts and no updates to the phone number table you would be fine. You would do inserts, updates, and deletes to the mapping table to manage these relationships.
You would have three tables. Contact, Phone_Number, and Contact_Phone_Number. Contact_Phone_Number would just have the contact id and phone number id. This would give you the many to many relationship.
To use this for example, if a user changes their number remove the mapping between the number and the contact in Contact_Phone_Number and set up a new mapping. If the number is new you would insert into Phone_Number. If it already exists just map to the existing phone number record.
The benefit of this is it makes it much easier to query which contacts share phone numbers since there is only one record per logical phone number. The decision depends on how you want to use the data.
it may be an old post, but if someone reads it...
you have contacts, vendors and phone. Contacts can work at the same vendor and maybe some contacts share the same phone number.
What I would do, is simply create 3 tables:
contacts:
id, name, vendor_id, phone_id
vendors:
id, vendor
phone:
id, phone
The relations between those tables are quite simple actually...
Related
I am writing DB schema for my application. App's users have unique phone number.
Every user can have multiple contacts. I have made user_contact table to have mapping between user and contacts.
contact is itself a user.
Now I came to know that every contact can have multiple phone numbers. Now I am thinking how this will be managed in DB.
Do I need a new table?
P.S. we are using mysql database with java 8.
There can be different ways.
If you assume there will be limited phone numbers for each contact, you can add multiple fields one for each phone number, e.g. PhoneNo1, PhoneNo2, PhoneNo3.
If you want to keep it flexible, you can add a table contact_phoneNos with foreign key of Contact, and keep a record for one phone number.
I suggest the first solution as its commonly implemented, like Home No. Office No, etc in each field
I have the following schema:
SINGLE_CLIENTS:
id - firstname - lastname - email - address - job
COMPANY_CLIENTS:
id - name - address - website - email
and I need to add phone numbers to both tables where each entity can have multiple phone numbers each consists of (id - number type - country code - number).
should I use two tables (i.e. SINGLE_CLIENTS_PHONES, COMPANY_CLIENTS_PHONES), just one table (i.e PHONES) or should I store them in a string that resembles an array? and why??
I would keep them in one table. This allows to have only one record for a phone number that is shared by a company and a individual, or use phone number in parts of your app that don't know anything about customers or companies.
Use lookup tables to relate each client type to phone numbers, as this is potentially a many to many relationship.
Get rid of the FOREIGN KEYs. Get rid of the restriction that "a phone number can only belong to one client (either a single one or a company)".
But, as long as you have two types of clients, you need two Phone tables. This will allow a "Client" to have multiple phones (fax, mobile, landline, etc). This is because the client_id needs to be in the Phone table, not the other way around.
I have a conceptual question.
My DB has a table that stores information about people. One of it's fields is their phone number (8-digit for my country).
The thing is that in some cases, two or more people will have the same phone number.
My question is: will it be a better choise to store the phone numbers on another table and then reference it by a foreign key instead of just storing them as a field?If so, will the result be the same for whatever the size of the DB is?
I don't know if this will make any difference, but the table will have no more than 600.000 - 800.000 records, and I guess the coincident phone numbers will be about 10% of the total records.
EDIT:
-Each record can have up to 4 phone numbers (two lines and two cells)
-Both cases will occur, there will be sometimes where the users will be looking for all the people having a specific number, and times where the user will want to know what are all the phone numbers a person has
Technically to be normalized, you would have a separate Phone number table and then a PersonPhonenumber table.
However, in practice I have rarely seen this structure for phone numbers and addresses. For one, it is easy to make a mistake and update more than one person's addess or phone when you only mean to change one. For another it adds an extra join that seems unnneeded to most people. You aren't really gaining much by going to this level other than a small amount of duplication.
The real decider is how you are going to use and update the numbers. If you want to update all the people with the same number frequently, it is better to go fully normalized. If you will usually only want to update one person at a time, it is probably less risky to only have a Person table and a PersonPhone Number table.
If you want history, then I would go with a person table and aPersonPhoneNumber history table. It would have the personid, the phone number, the startdate and the end date. So when John and Mary get divorced, his phonenumber woudl have an end date but hers woudl not and you could clearly see who had the number when.
If you have more then 1 phone number per person
There is a good reason to set new table like:
id, user_id, phone, type, description
So type could be list of
Home, Work, Office2, Boss, Wife, Fax, Mobile etc...
and description like
"work hours only", "evening", "24x7", "Emergency only" etc
If you really manage phone book for your application that is good idea to separate phone numbers from original user table.
If you have two people with the same phone number you will encounter a problem when searching for a specific phone number. A search for a specific phone number will sometimes return more than one result (10% according to your estimate). If you search by phone number AND by people, you can require all searches for a phone number to include a user identifier (first name, last name, location, etc). It depends on what your objective is.
Usually the phone number is just a number, and without a person has no meaning.
So you store it in the Person table.
But it you work for a telephone company for which a phone number has a different meaning and usage (like history, phone lookup, billing) then it should be stored in a separate table. I hope it helped.
I'll start of with what I have already:
I've learned at uni how to create databases and now I'm trying to create my own for personal use and possible use for my customer base. The people I work for are on the one hand businesses (Companies) and on the other hand privates (Customers).
I tried to build my database like shown above. I want to be able to add multiple addresses to both my customers and companies. I also have several employees that work for me.
Now, I'm pretty happy with what I have right now but I have the feeling it can be simpler but with the same capabilities (multiple addresses, ...).
Secondly, both Companies and Customers can make orders. Right now I only have a table for Customers to place an order and I'm clueless how I can do the same for Companies.
Should I make a CustomerOrder and CompanyOrder table to achieve this or is there a better solution?
EDIT
I played around a little and actually started over. I tried to take each part like email, phone, fax and put it in its own table. This way, if I update a phone number somewhere and it's used elsewhere, both will be updated.
Below is what I have so far:
Phone, Phone_1 and Phone_2 are the same table, Access just displays it that way. Any suggestions on how I'm doing? ContactType is used if there is CustomerSupport or TechnicalSupport. Type in EntityAddress is to determine if the Address is for a Person or a Company. This way it's expandable for more entities.
Now that I'm Writing this, would it be a good idea to do the same for Phone, Email and Fax like I do with Address?
What I would suggest you is to create a separate table for orders with no link to either customers or to companies. Then you create 2 intermediate tables to link order and company together on the one hand and order and customers together on the other hand.
Fields in the table will look like:
LinkID
CustomerID / CompanyID
OrderID
It avoids having twice the same table (order table).
For the phones, you can do the same thing. This way you can have as many phone numbers as you like linked to one company or customer.
I'm trying to figure out the best way to design these tables for a website I'm making for a school club. I want to set it up so each user can have multiple emails, phone numbers, and addresses tied to their account. To do this I tried to tie all these things to a contacts table and store the contacts id in the users table as a foreign key. The contacts id is also a foreign key in the emails, phone numbers, and addresses table. Is this a feasible way of relating these tables or should I just cut out the middle man (contacts table) and store the user id in the emails, phone numbers, and addresses tables?
Just in case my description of the relationships weren't enough, here is an ERD for the tables:
Sorry for such a "noob" question, it's been a while since I had to build a database with more complexity than 2 tables. Any general tips for database design are very much welcomed as well.
All you need to do is remove the Contacts table and store the user_id in the tables on the right, rather than contact_id.
Remove contact_id from Users as well.
I have dealt with this very question in the past. We did it wrong and we were sorry.
The determining factors should be these:
Will you have any other category of person that isn't a user, for whom you need to store contact information?
Will those kinds of persons somehow be "fungible" with users?
If you answer both these questions "yes," keep your contact table. Otherwise get rid of it.
The mistake made by a team I worked on was our answer to the second question. We had medical patients and doctors/nurses/etc as our categories of people. We stored their contact information together. But we shouldn't have done that because patients' contact information is very sensitive and confidential, but health care provider information is much less so. We were always wishing we didn't have the two kinds of data in just one set of tables after the system became successful.
Unless you can convince yourself you need your contact table, get rid of it, I say!
Yes I would cut out the midle man:
Although I was tempted to go the 'contact_type' route, I have found that there are usually validations and different data types which become more complicated when the contact is generic. For instance a table that has address fields is not the same as a phone number and having both presents more complexity and less readability.
This model focuses on simplicity, e.g. a user has many emails and an email belongs ot a user.
According to me you can design DB accordingly
Table 1 : Users
UserID //PK
Name
Table 2 : Contacts
ContactID //PK
UserID //FK to Users
ContactTypeID // FK to ContactType
Value
Table 3 : ContactType
ContactTypeID //PK
ContactTypeName
Description
Table 1 is pretty clear stores user information
Table 3 holds information about contacttype i.e email, home phone, mobile, home address, shipping address, etc
Table 2 holds information about user, contact type and its value
like cinatacttypeid corresponds to mobile than value is , etc.