Here is my pivot table project_group:
+-----+----------+------------+----------+---------+
| ids | group_id | project_id | admin_id | user_id |
+-----+----------+------------+----------+---------+
| 4 | 115 | 1 | 1 | [3,4,5] |
| 5 | 115 | 2 | 1 | [5,2,1] |
| 6 | 115 | 3 | 1 | [1,3,6] |
This table represent group linked to the projects....user_id is which users can see projects/group... Is there any way to display correct projects/group only to the users defined in user_id?
Also content in user_id field can be changed....
The best way to handle this would be to first normalize your database. Storing comma separated lists in a cell is allowed, but generally bad practice, as explained in this question.
If you can have multiple users per project, you should have a linking table with a column for project and a column for user, like this:
project_users:
| project_id | user_id |
and you can make (project_id, user_id) a composite primary key.
That way, you can select the users for a project (say, project 1) like this:
SELECT user_id
FROM project_users
WHERE project_id = 1;
Once you have these, you can display the project data only to users whose id is returned in the above list.
I have built an SQL Fiddle that helps demonstrate this visually, if it helps.
It is good to note that this proper normalization gives the opportunity to a lot of useful data as well, as it becomes easier to search for users by project, but also you can search for project information based on a user.
Related
I made a firm to add a user to my database now I want to have two tables. One table keeps track of the languages the user knows and the other table the design software the user uses.
Would I create 3 tables (profile, languages, software) each with an I'd field and when I add a user add a row to each table?
As you begin to add several many-to-many relationships, you need more tables to 'link' the information together. Here's how I would tackle the problem:
Note The IDs should all be unique indexed columns. Consider using AUTO_INCREMENT.
Table 1: Contains user's profile information
| ProfileID |UserInfo |
|=======================|
| 0 | Info |
|-----------------------|
| 1 | Info2 |
|-----------------------|
Table 2: Stores the possible languages
|LanguageID |LanguageName|
|========================|
| 50 | Python |
|------------------------|
| 51 | Java |
|------------------------|
and so on...
Table 3: Stores the Profile links to the languages
|ProfileID |LanguageID |
|========================|
| 0 | 50 |
|------------------------|
| 0 | 51 |
|------------------------|
| 1 | 50 |
|------------------------|
Every time you wanted to add a language to a user's profile, you'd create an entry in this table.
You would add two more tables for the software a user knows. One table for all the possible types of software, and another to store the links.
When you want to retrieve the information, you would do an operation such as the one below:
SELECT * FROM Table3
LEFT JOIN Table2
ON Table3.LanguageID = Table2.LanguageID
WHERE ProfileID = [TheProfileIDToSearch]
This structure uses JOIN to link tables together to return information from several tables at once. Here is a W3Schools quick explanation about SQL JOINS.
How should i store data like users's gender, religion, political views which is selecting from a list of 2-8 max values like 'male', 'female' or 'orthodox', 'muslim','judaism','catholic' etc? Also this values is constant, even admin cannot change 'female' to something else. In a Database it looks wierd to store a similar tables with only this 2-8 values and make JOIN with a parent table on foreign key. Second way - special object inside program code - but it's always bad to mix program logic with a data.
Whether or not something is looking "weird" depends on personal preferences or design structures. However, it is entirely logical to store anything in a database that has to do with, well, data. Even a given set of options can change in the distant or not so distant future. I can't count the times a client asked me to change a set of options a day, a week, or even a few years after having ensured me that the set wouldn't change, ever.
Storing a list of options in a separate table is part of a relational database design. Relational database designs make it easy to get a set of data which includes or even excludes the options in any way in my opinion.
I'd recommend doing it the good, old fashioned way, for example:
Table user (id, user_name)
Table option (id, option_label)
Table user_option (id, user_id, option_id)
A user that is both male and catholic would have a relation with two options:
Table user Table option Table user_option
+----+-----------+ +----+--------------+ +----+---------+-----------+
| id | user_name | | id | option_label | | id | user_id | option_id |
+----+-----------+ +----+--------------+ +----+---------+-----------+
| 1 | john | | 1 | male | | 1 | 1 | 1 |
| 2 | melody | | 2 | female | | 2 | 1 | 6 |
| 3 | gerald | | 3 | orthodox | +----+---------+-----------+
+----+-----------+ | 4 | muslim |
| 5 | judaism |
| 6 | catholic |
+----+--------------+
Showing all selected options per user can be done with the following query:
SELECT `u`.*, GROUP_CONCAT( `o`.`option_label` SEPARATOR ', ' ) AS `options`
FROM `user` AS `u`
LEFT JOIN `user_option` AS `uo` ON `uo`.`user_id` = `u`.`id`
LEFT JOIN `option` AS `o` ON `uo`.`option_id` = `o`.`id`
It must go in a table, even if it make you makes joins. The join will be done over a PK, so there is little overhead
I tried to make this inside this question, but i am too young on #stackoverflow to post comments.
MySQL returning results from one table based on data in another table
I cannot get this to work. My intentions are slightly different.
I have two tables (and more in the future) that I intend to work together. I want to keep my db size down, so instead of using full words to reference time_code_department, I added a column to reference the "department_id". now I want to grab all the "time_codes" from table where the "time_code_depart" id matches the variable entered.
So if user selects "Solar" department and time_code_department table has "9" as the "solar" "department_id", then i want to return all the entries in "time_codes" that have the "department_id" "9" on the time_codes table. Which in this example would be lines with id 40 and 75.
Table Structure:
----------------------------------------------
| time_codes (table) |
| |
| id | department_id | code_number | code_name |
----------------------------------------------
| 40 | 9 | 35 | Safety |
| 52 | 10 | 725 | Inventory |
| 75 | 9 | 18 | Cabinets |
----------------------------------------------
-----------------------------------
| time_code_depart (table) |
| |
| department_id | name | manager |
-----------------------------------
| 9 | Solar | John |
| 10 | Finance | Mary |
| 11 | Design | Sue |
-----------------------------------
I've tried to query:
SELECT 'department_id'
FROM `time_codes`
INNER JOIN `time_code_depart`
ON 'time_codes.department_id' = 'time_code_depart.department_id'
WHERE 'name' LIKE 'Solar'
and
SELECT 'time_codes.id', 'time_codes.code_number', 'time_codes.code_name'
FROM `time_codes`
ON 'time_codes.department_id' = 'time_code_depart.department_id'
WHERE 'time_code_depart.name'
LIKE 'Solar'
Both of these I formed based on several readings on the subject, and i have used several variation of sentax. I cannot get it to return the entries for the lines with id 40 and 75.
Can you help me identify where I am going wrong?
You have several problems with quoting.
First, to quote table or column names in MySQL, you use backticks; single quotes are used for making strings.
Second, when you have a table.column, you must quote them each separately.
Note that it normally isn't necessary to quote table and column names at all. They only need to be quoted if they're the same as reserved words, or contain punctuation characters.
SELECT `time_codes`.`department_id`
FROM `time_codes`
INNER JOIN `time_code_depart`
ON `time_codes`.`department_id` = `time_codes_depart`.`department_id`
WHERE `name` LIKE 'Solar'
And when you have long table names like this, I recommend making use of table aliases to make expressions more readable:
SELECT tc.department_id
FROM time_codes AS tc
INNER JOIN time_code_depart AS tcd
ON tc.department_id = tcd.department_id
WHERE name LIKE 'Solar'
I have a scenario and i'm confused about how i can go about designing the database schema for it.
In my software (php)
there are companies and applications.
companies need to have licenses to access applications.
now the fields (for form while purchasing licenses) for each application is different.
for ex:
for application1:
fields are:
no of users
no of groups
for application2:
no of users
for application3:
number of hours of usage
Prices are based on these fields.
Now i need to design schema for this so that on one page company can manage licenses for all applications.
How can i make this schema generic?
Please help.
Thanks.
You can go with this type of structure
select * from applicationMaster
| APPID | APPNAME |
------------------------
| 1 | Application1 |
| 2 | Application2 |
ApplicationMaster will go with main Application related details which won't be repeated such Name, date etc.
Query 2:
select * from applicationField
| FIELDID | APPID | FIELDNAME |
---------------------------------
| 1 | 1 | NoOfUsers |
| 2 | 1 | NoOfGroups |
| 3 | 2 | NoHourusage |
ApplicationField can adjust any number of field for a particular appId.
So AppId 1 has 2 fields NoofUsers and NoOfGroups. It is also capable to adjust newer fields for a particular app if you want.
Query 3:
ApplicationValue will have the values for every license aplication so it will have compId which represents which company has applied using fieldId which refers to applicationField table we can get for which app values are stored.
select * from applicationValue
| ID | COMPID | FIELDID | FIELDVALUE |
--------------------------------------
| 1 | 1 | 1 | 50 |
| 2 | 1 | 2 | 150 |
| 3 | 2 | 3 | 350 |
| 4 | 3 | 1 | 450 |
| 5 | 3 | 2 | 50 |
applicationPriceMaster stores the price package for each application. There could be multiple package for a application.
select * from applicationPriceMaster
| APPPACKAGE | APPID | TOTALPRICE |
-----------------------------------
| 1 | 1 | 50 |
| 2 | 1 | 100 |
For each application package its details will posted in this table.
select * from applicationPriceDetail
| APPPACKAGE | FIELDID | QUANT |
--------------------------------
| 1 | 1 | 1 |
| 1 | 2 | 1 |
| 2 | 1 | 10 |
| 2 | 2 | 1 |
NOTE Please check the structure as it is now too complex and check what type of queries you would be running on these table and its performance.
select apm.APPPACKAGE, TOTALPRICE from
applicationPriceMaster apm
inner join
(select APPPACKAGE from applicationPriceDetail
where FIELDID=1 and QUANT=1)a
on apm.APPPACKAGE = a.APPPACKAGE
inner join
(select APPPACKAGE from applicationPriceDetail
where FIELDID=2 and QUANT=1)b
on
a.APPPACKAGE=b.APPPACKAGE
SQL FIDDLE:
| APPPACKAGE | TOTALPRICE |
---------------------------
| 1 | 50 |
For single filter you have to use this query, so you have to increase number of inner query with the number of inner filter.
select apm.APPPACKAGE, TOTALPRICE from
applicationPriceMaster apm
inner join
(select APPPACKAGE from applicationPriceDetail
where FIELDID=1 and QUANT=1)a
on apm.APPPACKAGE = a.APPPACKAGE
NOTE-This query is quite complex and will only work if the values are same as mentioned in the packagedetail table and will work only if the values are 2 filter you have to remove 1 inner join if there is only 1 filter. So I suggest you to reconsider before using this approach.
What you have there, could be easily mapped to Classes in an OO language (like PHP). You have an Abstract License, and then 3 Subclasses (ApplicationByUsersAndGroups, etc). Then, mapping to a Relational database is a very common problem, here is a nice article about it: http://www.ibm.com/developerworks/library/ws-mapping-to-rdb/
It has 3 options, it depends on the way you want to structure your application which one you should use. I recommend reading it, it is not that long.
One way is
Table LICENCES:
LICENSE_ID ==> UNIQUE IDENTIFIER
COMPANY_ID ==> references table COMPANIES
APPLICATION_ID ==> references table APPLICATIONS
LICENCE_TYPE ==> either of "BY_GROUPS_AND_USERS", "BY_USERS", "BY_HOURS"
LICENCE_BODY_ID ==> ID of specific body table
[...]
Table LIC_TYPE_BY_GROUPS_AND_USERS:
LICENCE_BODY_ID ==> body identifier
NO_GROUP
NO_USERS
[...]
Table LIC_TYPE_BY_USERS:
LICENCE_BODY_ID ==> body identifier
NO_USERS
[...]
This way, your intention is clear. Even after long time comming back, you will know in no time how things are organized, which fields are used in which case...
how about a table structured this way:
LicenseId int PK
CompanyId Int PK
AppId Int PK
LicenseType int
NumberOfUsers int
NumberOfGroups int
NumberOfHours int
Price Money
Depending on LicenseType, you will use different column in your business logic,
you might need to add CompanyID and/or AppID, that depends how you going to structure those tables as well as relation ships between company/app/license.
Some questions to think about:
Can one company have different License Types for same App?
Can one company have different Apps?
Dont complicate things, if the number of users is unlimited then set it to 999999 or some other max value.
This keeps the license check logic (which will run every time a user logs in ) simple and the same for all applications.
You will need extra logic in the licenses maintenance application, but this should also be pretty simple:
if the cost_per_user is = 0 then set no_of_users = 99999
Again you end up with the same licensing screen and logic for all your applications.
Hey all,
I am setting up a PHP web app that will make use of subdomains for accounts. I am storing subdomains in a MySQL table with the following fields:
subdomain_id | owner_id | name | date_created
owner_id maps back to user_id in the user table The user table has the following fields:
user_id | email_address | etc...
Now I am trying to figure out what is the best way to store which users have access to which subdomain. Is the best to set up another table with the following fields?
id | subdomain_id | user_id
That would contain data such as the following (showing user #6 has access to subdomains 4 & 7):
id | sudomain_id | user_id
1 | 4 | 6
2 | 4 | 23
3 | 7 | 6
Is there a more efficient way?
That is the correct way to model a many-to-many relationship, but the id column is entirely unnecessary. You don't need to give every table an artificial identifier. The primary key of that table is simply (subdomain_id, user_id).