mysql database how to store contact data - mysql

I want to fetch contacts from phone
and store into mysql database
I have:--
User table
id,userId, name, username, password
Contact table
id
userId(foreignkey(from user table))
contact_name
mobileNo(unique-primary key)
email(unique key)
Now problem is:
1)Suppose I am fetching sonia's contact list
where,
she has one contact:-
Name mobileNo email
Soma 5675675675 aaa#mail.com
another user preeti's contact list has:-
Name mobileNo email
sree 999999385 aaa#mail.com
and again another user lila's contact list has:-
Name mobileNo email
mona 5675675675 agawasti#mail.com
In my database
mobileNo and email is unique-primary key,
but for every user name/email/mobileNo may be different..how I can store and manage these data
for individual user??
I got one solution :-
1] User_info Table
id | UserId | name | username |password
2] Contacts Table
ContactId | Contact_Name | Contact_Phno |Contact_Email
3] User_Contact Table
UserId | ContactId
but Here, in Contacts table how can I manage to store sonia,preeti/lila's contact information? because the values are different.

You can have only one primary key per table, but maybe you defined a composite key (can't tell from the question)? I would suggest making 'id' a primary key and to add uniqueness constraints on the mobileNo and email. This choice also plays nicely with most of the web-frameworks you might be using.
ALTER TABLE `contact` ADD UNIQUE `unique_index`(`mobileNo`, `email`);

check your data type for phone number. May be it is integer and your phone number is over its limit..

Related

How to store unregistered users in database?

I have a table that contains users of my system. The order table has columns:
id | user_id | price
Where user_id is foreign key.
Problem is that if user not registered there is no user_id. It means order cannot be placed because violates the integrity.
Make user_id nullable and insert a NULL, if there's no user associated with an order.
add a column to your user table where you mark if he is registered or not.
With this you can make the whole registration process, if need be, else you keep the unregistered users, till taxes and law it requires and the delete the users whenit is proper.

Data consistency and using session instead of foreign key and relations

I have a database with 15 tables that are connected between each other by different relations.
The main table is the login table:
login_id
user_name
user_pass
area_id
The area_id means that each area have it's own user and password so each action made, we can figure out in which area it happened.
Now instead of connecting all 15 tables into the login table with 1 to many relation and area_id is the foreign key, can I save the area_id in a session (because the backend language is PHP) and add it in each table without the relation.
So now, the user_info table contains:
name
address
phone
mother_name
contact
alternative_contact
area_id
But here this table is not connected directly to login table but it contains a similar field area_id and which it's value is added from session, and so we can now create a query by saying:
SELECT something FROM login JOIN user_info WHERE user_info.area_id = login.area_id
Does this makes data consistent or should I connect the login table with all other tables ?

Creating unique Key as FK - MySQL

I've an endpoint /user which creates an unique UUID for a user. It inserts the data(phoneno, gender, age) into the table(cassandra table) and then forwards the same data to another server along with the user_id just created, having MYSQL as the DB.
Now in my MySQL the table is as follow.
id(varchar)
phone no
age
gender
etc.
But I've read that using VARCHAR as PK is a very bad solution. Hence I modified my table as follow:-
id(interger auto increment)
user_id (varchar unique)
phone no
age
gender
etc.
I have another endpoint /recharge, which contains the user_id (UUID), recharge_amount, operator, etc..
My recharge table is as follow:-
user_id FK
amount
operator
Now the problem arises that whenever I'll receive the data for /recharge I need to get the respective id of the user from the Users table to reference it in the recharge table, which is an extra operation. ie for every insert, there will be an extra read operation.
Can I reference/use the unique key as my FK in the recharge table. If no, then what can be the possible solution?
Yes, you can use unique key as foreign key.
To use a column as FK in other table it has to be a PK or a Unique Key.

How to set up rating table SQL

I'm trying to figure out how to set up a database table that will handle rating of specific users. Every user is one "blog", I would like users to be able to vote other users.
Table users
id(primary) username password email
Table rating
value user_id(foreign key)
The problem is that I can't find out, how to make another user able to rate the other user, and store it in the rating table. I would like it to look something like:
user id 2 voted user id 3 with value 5.
Maybe you should consider changing your tables to something like this:
Table users (id (primary key), username, password, email)
Table rating (rated_by_user (foreign key), rated_user (foreign key), rating)
Both foreign keys would refer to users.id.
then an insert statement like insert into rating values (2, 3, 5); would indicate that user id 2 rated user id 5 with rating value 5.
The rating table should probably have a primary key (rated_by_user, rated_user) too.

Database design: different fields for multiple user types

I am building an application using MySQL 5.0.77 that contains
a) different user types (e.g. carpenter, mechanic, ..., plumber)
b) different input fields for each user type, e.g. user selects carpenter and is presented with fields pertaining to that profession, where the fields for each profession are different
My thinking is along the lines of:
Table: users
user_id
user_name
Table: carpentry
user_id
woodwork_rating
metalwork_rating
Table: plumbing
user_id
central_heating_rating
bathroom_rating
And so on...
This does not seem very good though since I could potentially end up with lots of tables and users existing in multiple tables with different fields.
I quite like the idea of a metatags table (like we see in Wordpress) so that each users field entry is stored, e.g.
Table: user_info
user_id
field
value
So we would have for example
1 | woodwork_rating | intermediate
1 | metalwork_rating | advanced
2 | woodowork_rating | advanced
My question is, how would you structure a database that has multiple fields for multiple users for which each user only fills in one category of the available fields?
Thanks
Table Users:
UserID: Autoinc PRIMARY KEY
(More user data columns here)
UserType: CHAR(5)
Table UserTypes
UserType: CHAR(5) PRIMARY KEY
Description: VARCHAR(50)
Table UserRatingList
UserRatingCode: CHAR(5) PRIMARY KEY
UserType: CHAR(5) REFERENCES UserTypes
Description: VARCHAR(50)
Table UserRatings
UserID: INTEGER PRIMARY KEY / REFERENCES Users
UserRatingCode: CHAR(5) PRIMARY KEY / REFERENCES UserRatingList
Rating: INTEGER (or whatever you prefer)
The table UserRatingList establishes the pattern of ratings that can be applied to each user type. UserRatings contains the actual ratings. I use CHAR(5) to provider readable codes without having to join in the Description fields, but you can change them to INTEGER if you want.
This structure can also be adapted to allow each user to have multiple types; simply create an addition UserTypeLinks table with UserID and UserType.
i would like to rely on 'mike' s last answer.
i am facing this exact problem. i am creating a network with the following types
Enterprise {name, mail, adress, etc ...}
Employee {name, mail, branch, jobdescription, etc ...}
Individual {name, mail, surname, age, town, etc...}
how about:
Table Users
userID (autoincr)
userType
mailadress
password
...
Table Usertypes
typeID
typeName
typeDescr
Table Enterprises
entID (autoincr)
userID
field 1
field 2
...
Table Employee
empID (autoincr)
userID
...
Table Individuals
indID (autoincr)
userID
...
does this make sense to you?
Are all the fields going to be "ratings" with the same datatype? If so I like Larry Lustig's solution.
Or could there be unrelated fields with different data types? dates, strings, decimals, integers? If so, the first solution of having 1 to 1 related tables that join with Users is OK. As long as you don't need to dynamically add new fields at run time.