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
Related
I have 4 tables,one is credentials(it holds an id, email and password), the other 2 are for business users and regular users of the app.
The business users table holds crID(foreign key)name,lastname,address etc...
The regular users table holds crID(foreign key),name,lastname etc...
The 4th is the booking table, it holds a bookingID, bookedfrom,bookedfor(the last 2 being foreign keys that point to the credentials table).
If a regular user registers in the site he closes a bookingslot and that is stored in the booking table, his name,last name are stored in the regular users table and his credentials in the credentials table.
The business user table just holds the business user for which a booking is made by the regular users.
Here is a graph:
db image
The question is what to do if a regular user does not choose the web to make the booking but makes a call. The business users are given the option to make the booking "manually" also. I am just having difficulty how to integrate that in the db.
As I see it I need to make the following:
Create a booking slot in the bookings table
Create a new regular user entry in the regular users table and at the same time create another column that would indicate if the user is registered or not.
create an entry in the credentials table but without password/email since this he will not be a registered user...he just made a booking using the phone.
WHat is your opinion.If you want I will post some show create statements. I think I made my point.
I would personally merge business users, normal users and optionally credentials in one single userstable.
Since I don't see the need of two seperate tables for your users, it would simplify drastically your data model. You just need a flag to determine if the user is a business user or a normal user.
For the rest, I think that having a null password is enough to determine if the user hasn't registered yet.
Current:
Table 1
Dbase(table with account information)
-id……
Table 2
Phonenumbers(table with phone numbers associated with accounts.
Id, maindbaseid, phone type, phone number
Current Rusult
Id1,phonetype1,phonenumber1
Id1,phonetype2,phonenumber2
Id1phonetype3,phonenumber3
Wanted result
Id1,phonetype1,phonenumber1,phonetype2,phonenumber2,phonetype3,phonenumber3.
I am trying to export data from our MySQL database based on 2 tables. One is in relation to the other based in the id column and main database id column. The one table is information on an account, and the other is phone number associated with that account. The data I am trying to export needs to be the information from the account table with each phone number associated with that account in rows next to each other I tried an inner join where maindatabaseid and the column maindatabaseid from the second table matched but it only shows the account duplicated as many times that there is a different phone number. Any suggestions would be appreciated, I am a beginner at MySQL so if you could explain things simpler it would help.
This is one of the most simple relationships. All you need todo is setup a "Foreign Key" relationship, from say the "phone numbers" table to the "accounts table" That way when you query the phone number table, you will then be able to access all the information from the account related to that phone number. (or the other way round)
Please see this documentation on Foreign Keys and how to use them, depending on whether you are using a raw sql connection or an ORM would depend on the best approach on performing your query, the documentation link provides information on using the MySQL console.
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.
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've a problem deciding where to place a certain table field within my database.
The database is for a classified ads website.
I want registered and non-registered users to be able to post ads. If an unregistered user posts an ad, the site should ask him for the contact phone, if the user is already registered, then the contact phone stored in the users' table should be used.
Now my question is, would it be possible to store the contact phone for both registered and unregistered users in the same table field?
If so, where should that field be put, in the Classified ads table, or in the users' table (noting that each user within the table has a unique Id, thus, filling the users' table with unregistered users just to get their contact phone will just fill the table with useless data)
Thanks in advance !
well you can put the phone field in the ads table, with a is_registered field inside. Then via php you check is_registered and then you know where to search for phone number.
Regards
You can store unregistered users' phone numbers in the same column of the same table, and you probably should. It makes the transition from unregistered user to registered user dead simple--you don't have to move or re-enter phone numbers. And if any user changes phone numbers, it only has to be updated in one place. (Do you know how many people accidentally drop their cell phones in a toilet every day? It's staggering.)
If you're now relying on the presence of a phone number to identify registered users, you'll need to fix that first. (I don't think you're doing that, but if you are, fix that first.)
You said
filling the users' table with
unregistered users just to get their
contact phone will just fill the table
with useless data
If it's useless, don't store it. If you need to store it, it's not useless.
You can always delete unregistered users when their classified ad terminates. But . . .
Does it make sense to require a contact phone number instead letting the user choose to leave either a phone number or an email address? Personally, I prefer to use a throw-away email address for things like this.
I would look for flexibility in your design, but if your logic treats users mostly independently of whether they are registered or not, I would use the same table and just complete the rest of the user's data for the registered ones. I wouldn't store user data on the ads table, even if only for clarity of data organization.
I guess your registered users will all have a username and password, so you can just check the presence of these to know if they are registered or not. If you don't want to change your logic in the future you should choose this distinction carefully of course.
A different approach: Why not making registration so easy that it makes no sense to have unregistered users? I you are already asking for a phone number in all cases, just add a password field or generate one automatically and you have all your users registered.
I would ask for an email so you can send the password and perhaps ask for account verification (now or in the future).