Now, whenever a new user will sign-up, I will generate userId for this user(u1), add one row into User_Info table and create a u1_Info table (this table belongs to this user only)
If the userId is unique, but the username is not, the userId should be the primary key. Remember that in the real world there are lots of people with the same names.
What do you imagine would be in this field? If it is the name of the country, remember that different languages have different names for different countries ("Deustschland" vs "Germany" vs "Allemagne", for example). Unless you have a very strong reason, I would suggest using something like the international two-letter country code.
I don't quite understand what you mean by this, but it sounds like very poor design. Any relational database with long compound fields like this is dangerous and wrong.
If you mean that each user can be in multiple bulk groups, and each bulk group can have multiple members, what you have is a "many to many" relationship. The usual way to solve this is to create a table containing the ids (and optionally descriptions etc.) of all your groups, and then make a "linking table" where each row contains the id of a user and the id of a group. Then if you need to find out if a user is in a particular group, just ask the database for rows with that userid.
Do you imagine you will be asking the database to look inside this field during queries?
Instead of a whole new table for each user, just add a column for the user id to this data, then the database can select out just the rows for that user. Much simpler. Let the database do the work.
Actually both username and userId are unique, username is not the name of user, it is mail Id of user. Actually I forgot to add name column in User_Info, may be because of that, this confusion gets created...
Why I made username is unique and userId is not unique because, username will be entered by user (I can't make sure that user will enter unique always) and userId will be generated by system (so I will take care of uniqueness here).
May be I didn't understand it completely, but I am not using 'country' for programming, it is just information about user that will be in database always....
A sample value for bulkList is like this:
john_123,smith_passion,ramkumar,shankar.prasad
I am confuse, how it is dangerous, wrong and poor design? Could you please put some more light on this...
If you mean that each user can be in multiple bulk groups, and each bulk group can have multiple members, what you have is a "many to many" relationship. The usual way to solve this is to create a table containing the ids (and optionally descriptions etc.) of all your groups, and then make a "linking table" where each row contains the id of a user and the id of a group. Then if you need to find out if a user is in a particular group, just ask the database for rows with that userid.
could you please explain this with an example if possible.
Do you imagine you will be asking the database to look inside this field during queries?
probably No, no need to look into the value of any field except messageId. But I am not sure, what exactly you wanted to point out?
You mean, two column into Message_Info table. One is senderInfo and second one is receiverInfo. The type will be varchar(25), and the sample value will be something like this....
Is this what you are suggesting???
Don't touch me. And dont' touch this tiny ad:
The Low Tech Laboratory Movie Kickstarter is LIVE NOW!
https://www.kickstarter.com/projects/paulwheaton/low-tech
|