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.
Related
I'm sure this has been asked somewhere, but I keep only finding discussions about phone numbers.
I'm designing a system for a supplier group that controls multiple online stores. There are 5 different types/levels of stores (based on their buying group, blah).
These accounts can order products from our warehouse and also have their own collection of customers that can order products from them.
Since both store accounts and their customer accounts will be stored in and accessed by our system, but stores will be accessing their customer accounts independently I want to set up an 'organized' structure for account numbers, that works for both sides of the system.
I was planning on doing 10 digit account numbers, with the first 5 digits identifying the store (the first of which will identify the store type/level), and the last 5 the customer.
For example,
First LEVEL1 store account : 10001-00000
Their customer accounts : 10001-00001, 10001-00002, etc.
Third LEVEL2 store account : 20003-00000
Their customer accounts : 20003-00001, 20003-00002, etc.
This should allow for enough growth to support our potential number of stores and their number of customers.
My question is, should I separate the numbers with a dash or not?
It certainly makes it clearer for humans, but it feels like it would be better in the database to be stored as a true int, though I don't know how often I'd be comparing them, etc.
Should I store it as an INT with no dash, and just format it when displaying it to users? (then obviously be sure to accept account number input with or without a dash)
1NF says that values in each attribute must be atomic. You are violating the 1NF by adding dashes and storing two attributes as one.
What must you (ideally) do?
Each store has an ID, so the store's table should have an ID column that contains that.
Next, the customers should also have their own IDs in their table.
Finally, the relationship (or junction) table between store and customer should contain store's ID and customer's ID as each row.
Alternatively, the customer can have a foreign key which tells which store the customer should be shopping from, assuming a customer is tied to only one store.
I recently took over a website where people can register to help tutor kids. Part of the user's details is which areas they could work, represented by postal codes. The problem is, my predecessor designed the site such that in the database there is a Boolean column for every postal code. As such, the user table has almost 270 columns and can be quite slow at times (plus it's a nightmare to administer).
Most users select only a few postal codes so there is surely a better way to do it. I was thinking about a varchar that could save the selected areas comma separated, e.g. 6043,8811,1234
Any advice from somebody who's had the same problem?
both your predecessor's and your solution are... strange.
You should simply have a relationship table between user and localities (assuming you have a locality table, with a postalCode field and a surrogate key (id)).
UserLocality(userId int, localityId int)
so a locality could have many user, and a user could have many localities.
Coma separated fields is a really bad idea, when query time comes.
You should throw that entire idea out of your head and look into properly normalized data.
A possible solution to this problem would be a table for tutors, which has an id column to uniquely identify one tutor.
Then you would have a table for just Postal Codes (each with unique ids as well) and finally a tutor_availability table that creates one record of (t_id, pc_id) for each postal code a tutor wishes to offer their services, again with a unique id to avoid duplication risks in the case they can select the same location twice.
I am trying to implement a customers list in an application that I derive the DB from MySQL,
Currently we would take the first and last name, dob, and phone number of said people.
To search for the customer we may enter a phone number and ideally it will find the person with the correct phone number - but I want to enter a fail-safe - lets say the previous representative entered the phone number slightly incorrect lets say the phone number is 7777777777 and the person accidentally types 7777077777 I would still want it to show up in query of course in order of relevance - so 7777777777 would be the preferred and top result.
Select * from Customers WHERE Pnumb Like....
would be what I would expect however I would not know how to implement that.
Any help is greatly appreciated as I can not find much (any) information on this online.
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...
I have 2 tables for a contacts book application
first one (called members) includes Full Name and Unique ID
second one (called phones) includes ID (phone ID) and memberID (to which member this phone belongs) and phone number.
To display the member's phone numbers.
Should I add a new field to the table members to store an array of phones IDs and update it every time a member add or delete a phone to his contacts book?
to print the contacts book, i will get the array and make a query to the phones table!
or
not store the ids in the members table. and just make a query where memberID=XX
which one is better and faster?
Your second option is much simpler to program and troubleshoot. Use it.
Your first option is called "denormalization" in DBMS jargon. Sometimes it makes sense to denormalize a database with very large tables, to speed it up. But mySQL is a good relational database, and works well with normalized tables as you describe.
When your application grows and you have, say, more than one hundred million rows in your telephone-number table, you may find that denormalization makes sense. For now, it doesn't.