Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I am a beginner to databases.I am working on site where i have to save education qualification in database for different users.for e.g
There is a user Alex.He is graduate in Computer science from Singapore
University in 2006. He is also masters in Computer Science from Canada
University in 2009.
It will be different for different users.
Should i try a new table for all the education qualification and give id to user table.
Select * from users,education;
How can i save this in database keeping best practices in mind ?
Thanks In advance. :)
You'll want to normalize your data, which means remove redundancies and inconsistencies. While you can get away with doing a very crude version of the layout with 2 tables where you allow a user to have multiple educations, you'll want to make sure that you're not creating more work for yourself going down the road.
The problem with the 2 table layout is that you may have records for the same schools, degrees, or majors, but they may be entered differently.
So if you did a search like `SELECT * FROM users INNER JOIN education
ON users.user_id=education.user_id WHERE education.major LIKE '%Computer Science%' you might not return all of the results for related majors if some of the majors are entered as something like "CompSci."
So you might actually have multiple tables. An example of these multiple tables might be:
users
user_degrees
schools
degree_types
majors
states
countries
Your table structure for user_degrees might look something like this:
user_degree_id (INT)
user_id (INT)
school_id (INT)
degree_type_id (INT)
major_id (INT)
graduation_year (DATETIME)
Schools would look something like this:
school_id (INT)
school_name (TINYTEXT)
school_city (VARCHAR(45))
state_id (INT)
country_id (INT)
Degree types might be:
Associate of Arts
Associate of Science
Bachelor of Arts
Masters
Doctorate
etc
There are several other types of degrees.
You get the idea. Basically, the premise is that you enter the information for each type of record once, then you can cross relate that information with the various tables without needing to enter it again. Also it allows a global change to any records using that same information.
Here you can read more about Database normalization.
You must have created 2 tables like users and education
Users table structure is like
id username etc etc
education
id user_id course/degree
then you can fetch is like
select * from users as u ,education as e where u.id = e.user_id
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I'm designing a database for social media which is similar to facebook structure. I'm using MySQL. The main goal for our database is the performance, it must handle a high number of requests.
I have a list of users, friends, posts on wall, comments and likes.
Q1- for users, I have several types of users, I have normal users, supervisors and admin. for that table, I'm thinking to define one parent user table and then inherit the information, but at the same time the fields are same.
example:
user
=============
id
username
password
email
isAtcive
country
noraml_user
===============
name
..
..
user_id
supervisor
==============
name
..
..
user_id
admin
=======
name
..
..
user_id
I considered this method because of performance, so instead of searching for single user using user type in (one million users as an example), I search for (300K users in table supervisor). Am I right?
Q2- I have likes for the posts and comments. here is my design
posts
==========
id
content
comments
==========
id
content
post_id
posts_likes
==========
id
post_id
user_id
comment_likes
==========
id
comment_id
user_id
Do you think this is correct, or I just make one table for likes such as the following
likes
=========
id
post_id(nullable)
comment_id(nullable)
user_id
what is best approach?
Q3- Could you provide me some tips to be considered for designing social network database?
Thanks :)
Q1: You shouldn't create separate tables for different user types. In fact, you should have a user role column in a common user table. This role would then define what the user can do. The whole point of indexes is to efficiently find subsets of a table.
Q2: Again, you'll probably find that you have content and likes (or maybe even "reactions"). Unless there's a specific reason to keep posts special, they're really just content that has no parent.
Q3: Yeah, so that's way to o broad a question for a site like this.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I have a small app in php using the cakePHP framework connected to mySql database.
I have two types of users (business and employees) with relationships to other tables also. I am now adding a login facility which means I will be adding a users table to hold the password details. So both employees and businesses will be able to login.
I am not sure what way to add the relationships between the users table and the businesses and employees table. I will be adding an admin role also.
My current tables are:
- course_files
- course_modules
- courses
- courses_employees
- employees
- businesses
My Choices:
Merge the businesses and employees table with the users and have a
users (id, role employee_name, business_name, business_address, etc)
roles (admin, employee, business)
My issue with this approach is that the fields for businesses and employees are very different so the users table will have a lot of fields. But it will make it easier for the login functionality.
Add business_id and employee_id to the users table. This option will be a little more involved and one field will always be blank like employee_id.
users (id, employee_id, business_id, role)
roles (admin, employee, business)
employees (business_id)
businesses
So before I go down one route and find I went in the wrong direction I was wondering what would be best practice?
I disagree with both of your approaches. I would have a users table for login, and tables for employees and business, just like you suggested in your second approach. The difference is that I wouldn't have employee_id and business_id in users because, as you've already stated, one will always be blank. Why don't you instead have a user_id in both tables, as they will always have a user profile (intended for login)? I see you use CakePHP, so these will be relationships as follows:
User hasOne Employee
User hasOne Business
Employee belongsTo User
Business belongsTo User
Let me know if any other business rules in your application make my approach hard to implement.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm trying to decide the best possible way to structure my user table. Users can have access to multiple "brands" and each brand will have multiple tables. That is, if user X wants to see data for brand Y, the database contains the information to say which tables I need to make calls to.
For example, user X can access Brand1 and Brand2. Brand1 has its data in table1, table2, and table3. Brand2 has its data in table4, table5, table6. User selects Brand2 and the application makes a call to find out that table4, table5, table6 should be used until user selects a different brand.
What's the best way to structure this knowing that a single brand might have multiple users that can access the data?
Do I need more than just a user table and, if so, what else and how would that connect to the user table?
Thanks.
Like Mark Baker pointed, you can have one user table, one brand table and one user_brand table.
user table - stores user_id (and other user data)
brand table - stores brand_id (and other brand data)
You've already defined relationships between users and brands. It's M:N (many to many), which means that:
one user can have access to multiple brands.
one brand can be accessed by many users.
Table user_brand solves the access problem.
user_brand table - stores user_id and brand_id (and optional data which better describes this relationship).
Here is an example about sql syntax (enforcing foreign key constraints).
You can use GRANT query so the user can access just 2 tables in a database, then in the application, you can code it just to select 1 table, until the user changes the brand. The brand itself is the table, isn't it?
In PHP code, the code and query should be like this:
<?php
$db = new mysqli('hostname', 'db_username', 'db_password', 'db_name');
$brand = $_SESSION['brandName']; // use this if you use sessions to cache the data
$db->query("SELECT * from `$brand`");
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I'm wondering about a potential problem I might get. My problem is let's say I have 2 tables one called speakers and clients. In the client table the client has the speaker IDs of 1,5,8(SAVED in a STRING field) - so I'm using explode() to get the values.
So now I have to call the speaker table 3 times to get the values of each speaker. This introduces the problem that it will get very expensive if there is alot of users online wouldn't it?
Is there an alternative to calling a table from an array of items or something?
I'm not too clued up about all the php approaches to this so any help will be appreciated!
I agree with #RiggsFolly that it may not be the best way to store the data, you could do something like this:
SELECT (whatever fields you want or speakers.* for all) FROM speakers JOIN clients ON clients.id=(clients.id) WHERE speakers.id IN (clients.field_with_speakers_list_string);
I believe that will get you going. It should return what you want. You would just need to replace (clients.id) with the client ID that you already have in your script and change speakers.id to whatever the ID field in your speakers table is called, and change field_with_speakers_list_string to whatever the field in your clients table with the string of speakers is called, and of course change the part of the SELECT to the fields you want to limit it by.
Based on the description of your database, each Client can have multiple Speakers. This is a one-to-many (1-N) relationship, and is typically expressed in two tables. One is a main table, "clients", which stores information about the client, but nothing about the speakers. A subordinate table, "speakers", stores information about each speaker AND the ID of the Client it is associated with.
For example, Speaker 1, Speaker 5, and Speaker 8 all have the same Client ID in the speakers table. The client_id field in the speakers table is called a foreign key.
Now you can get all the speaker information for Client 1 in one query:
select * from clients, speakers where clients.clientid=speakers.clientid and clients.clientid=1
Your current two-table design is flawed because you have the speakeridS column in the clients table. The foreign key column that expresses the ONE in a 1-N relationship should always be in the "many" table, i.e. "speakers".
Since your current speakers table doesn't have client_id information, you'll have to write a data transformer to migrate the string, comma-delimited speakers field in the clients table, to a numeric foreign key field "clientid" in the speakers table. This is a one-time transformation so you can do it in a PHP script:
$query="select * from clients";
$rs=mysql_query($query,$db);
while ($myrow=mysql_fetch_array($rs)){
$clientid=$myrow['clientid'];
$speakerids=explode(',',$myrow['speakers']);
foreach ($speakerids as $speakerid){
if (!is_numeric($speakerid)) continue;
$query="update speakers set clientid=$clientid where speakerid=$speakerid";
mysql_query($query,$db);
}
}
Your application displays the speakers in a checklist. The interface, however, doesn't have to dictate your storage structure. Write a loop and store the client ID in each speaker record.
IF the same speaker works with multiple clients, then you'll need a many-to-many (N-N) table. This is done via a bridging table. In this case, neither clients or speakers table need to know about each other. Create another table called "clientspeakers" which includes at least two foreign keys: clientid and speakerid.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I have database with a user table like so:
table users:
user_id (int)
user_name (varchar)
etc..
This user will be able to fill in a couple of requirements like:
Minimal Salary (int)
Has driver's license (bool)
My other demands (text)
The return value of the User->get(user_id); must be something like this:
user_id: 1,
user_name: 'John Doe',
user_requirements: {
minimal_salary: 2000,
drivers_license: true,
demands: 'These are my demands..'
}
What will be the best way to store this in a Database?
I know you can use a 1 on 1 relation. (it will cost a join or seperate query)
You can store it all in 1 table. (it will cost some tweaking in de code)
You can normalize this in to many to many relation with a type (int/bool/text) in the requirements table.
EDIT
NOTE: I already have 25 columns in the user table, so would it make any difference if I add 3 till 6 columns of demands? For the eye it will get a lot of information in 1 table.
Use only one table to store this data, as i can not see if there is any complexity:
Option 1: (Use only one table)
|--------|-----------|----------------|-----------------|------------------------|
user_id user_name minimal_salary drivers_license demands
|--------|-----------|----------------|-----------------|------------------------|
1 John Doe 2000 true These are my demands..
|--------|-----------|----------------|-----------------|------------------------|
Option 2: If the parameters are more for user requirements then you can make two tables one for users and other for requirements and you can have user_id as foriegn id in the other table. and then can use a join to retrieve the records.
Hope this helps.
Unless you provide the ability to let the user specify their own fields, I see no reason why you should break the information into a separate table. All of those information fields apply to a single, distinct user.
Since there is no data that is common for other users, you can store it in one table.
If the demands for instance would be selected out of a list then I would suggest to store that possible list entries in a seperate table.
If you just don't need every field all the time, then select only the fields you need
don't do
select * from users where user_id = 123
do
select minimal_salary, drivers_license from users where user_id = 123