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
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 5 years ago.
Improve this question
I am trying to insert a column in a database table automatically using a variable.
I have a table named tbl_category, I want to let the user choose the sub category field by their own choice. So, from the dashboard, the user will insert 3/4 (or how many fields they would like to create) sub category fields.
I will take this value as $insert_sub_cat_count. So, when this info will hit the function named function save_category_info($data), the function will receive the value $insert_sub_cat_count as $data.
After that, this info have to implement in the table tbl_category and add 3/4 fields automatically according to the value $data.
If the user inputs 2, this will insert two columns automatically:
If the user inputs 3, this will insert 3 columns:
Is this possible? I don't know how to extend columns automatically or if there's any other way to do so.
This is a bad idea from the very start. As Raymond Nijland said above ("the same column names with increment are a SQL anti pattern.. you should check table normalization instead"), you shouldn't allow users to create columns with their desired name in your database. You should have the following tables:
user - id, name
categories - id, id_user, name
subcategories - id, id_category, id_user, name
So you will be able to link the category and subcategory to the user that created it. You don't need to create a separate column for each user.
If you're worried about speed you should add index for the subcategories table, for the column: id_user. In this way the search will work fast enough.
Insert is used to insert variables into an already existing column, you need to first create your column before filling it:
ALTER TABLE `tbl_category` ADD `sub_category_one` VARCHAR(100) NOT NULL;
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 7 years ago.
Improve this question
I am looking to implement a new database and store students exam data and marks in the database. There are an arbitrary number of students and each student has an arbitrary number of modules with corresponding marks. I need the database to be created so that I am able to query the database and return the students name followed by each of their modules and corresponding marks and then to move onto the next student. This is because I want to display it in PHP with a list of students names in bold and then a table of their modules and their marks.
I initially considered to organise the table like this:
| StudentName | Module | Result |
With a new entry for each module that the student takes and just store multiple students but then I do not know how I would then query the database and retrieve each StudentName individually and then be able to loop through their corresponding modules and results to store it in an HTML table.
Any ideas would be appreciated
Give each table an id field that auto increments
Where you need to link results to modules, for example, you'd add a
moduleID field to the result table to tie the result to the module.
You'd then do queries with joins to bring in both sets of data.
To tie students to modules, you'd need another table that has a
studentID field and a ModuleID field. You'd then query this table
and join on StudentName and Module to get the respective data for
each.
First, you need several tables. One table cannot do it. Create a table for each type of objects. In this case, you need a table for students and one for modules.
Both tables need an id column to identify the rows. Create a primary key on them.
Students table: Id, StudentName
Module table: Id, ModuleName
There is a many to many relationship between students and modules (each student can have more than one module and each module can be chosen by many students). A many to many relationship requires a separate table.
You were not clear if there is one grade per student and module. If there is only one grade, the best solution is to include the grade in this relationship table.
Grade table: Id, StudentId, ModuleId, Grade
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 am new in Laravel, I want to have like button on my website
My Post Table:
post_id | body | created_at
My like table:
like_id | user_id | post_id | timestamp
Questions:
1-How to count likes in Laravel?
2-Is my database structure true or not?
3-I am going to have reputation (Like stackoverflow), Should I save that republication in one field in user table or it has different structure?
You can count results with Laravel using count() method. For
example to count all likes in the table:
// Eloquent + Query Builder
$likes = Likes::all()->count();
// Query Builder
$likes = DB::table('likes')->count();
You might want to look at the aggregation methods Laravel offers.
The structure of the two tables you showed looks fine. One thing to consider is what should happen to respective likes when a user or a post gets deleted (ON DELETE ...)
You could put reputation field in the user table, but the cleaner way
to do it is to create separate table for reputation with a foreign
key to user ID.
I would add the total like count to the post table as well. If you don't add it you need to perform sum() queries all the time, which might put too much load on your database (depending on the numver of visits on your site, etc).
You can save the reputation in the user table. You probably want to add something like your like table though. Users for sure want to know why they received some more reputation.
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