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`");
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 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 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 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 9 years ago.
Improve this question
Let' say I Have 2 tables, webpage table, and a keywords table. It's a many to many relationshiop, right? One webpage can contain more than one keyword, and one keyword can be part of more than one webpage.
Webpage table contain id field as PK, and few other fields. Keywords table contain id as a PK, and also a few other fields. Third table, a child table, should contain id fields from both parent tables? Is it posible to track many to many relationship, with no foreign keys, just declaring this 2 id fields in child table as UNIQUE?
With or without FK's, when inserting new keywords for example through PHP, how should I refer, to which webpage this new keyword belongs, webpage id in a webpage table, or a id in a child table?
I would do something like this...
Table1
Table_WebPage
PageID, PageName, Url,...........
Table2
Table_KeyWords
WordID, Word, .........
Table3
Table_PageKeyWords
ID, PageID, WordID
Dont know why you want to do it without FK, Having FKs will enforce the data integrity and stop garbage data coming into your tables.
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