Okay so I'm creating a task manager for my company. A user can assign assign a task to multiple other users. So I've though of 2 ways of implementing this.
This is my tasks table for option one (at least the columns that are important in this discussion ):
----------------------------------------------
| id | assigned_to | assigned_from |
---------------------------------------------
| 1 | 1,3,6 | 4 |
--------------------------------------------
| 2 | 1,4 | 2 |
---------------------------------------------
So here I pretty much just comma separate each user_id that is assigned to this particular task
Option 2:
----------------------------------------------------------
| id | task_id | assigned_to | assigned_from |
------------------------------------------------------------
| 1 | 335901 | 1 | 4 |
-----------------------------------------------------------
| 2 | 335901 | 3 | 4 |
-----------------------------------------------------------
| 3 | 335901 | 6 | 4 |
-----------------------------------------------------------
| 4 | 564520 | 1 | 2 |
-----------------------------------------------------------
| 4 | 564520 | 4 | 2 |
-----------------------------------------------------------
So as you can see here instead of putting the assiged_to is's here I just create a task id which is a random number and then I can groupBy 'task_id'. This is currently they way I have built it but for some reason it feels like it might screw me over in the future (not that option one doesn't give me the same feeling). So my question is which way do you guys recommend or is there maybe a different better way that I could be doing this?
Option 2 ist the better solution since you can acutally work with the table. You may e.g. create another table Tasks with
Task_id | Task_name | Budget | ...
Or a table with user-IDs for assigned_to and assigned_from. All these tables can be joined together if you use 2nd Option.
btw it is the correct normalization form
You can use Option 2 and normalize further if tasks are always assigned by/from the same person.
Tasks table:
task_id | assigned_from
1 | 4
2 | 2
The Assignees table then doesn't need to have the assigned_from since it's always the same for that task_id:
id | task_id | assigned_to
1 | 1 | 1
2 | 1 | 3
3 | 1 | 6
4 | 2 | 1
5 | 2 | 4
Related
I am working on a project for recharge and bill payments. I am confused about whether to use a single table for all type of recharges like mobile recharge, dtn recharge, electricity bill, water bill, card recharges, etc, which is difficult or do I create separate tables for each type of recharge and work on them.
Table has colums
recharge_id PRIMARY KEY,
recharge_amount ,
recharge_status,
recharge_time,
user_id,
payment_id
The data has to be added into the table when there is any recharge process with status and other details.
Although, you didn't show anything you tried, i think this is a viable question.
A possible approach would be to create one table for your type and one for your recharges
Something like the following should work
create a table recharge_type like
+----+------------------+--------+
| id | name | active |
+----+------------------+--------+
| 1 | Mobile recharge | 1 |
| 2 | Dtn recharge | 1 |
| 3 | electricity bill | 1 |
| 4 | water bill | 1 |
| 5 | card recharge | 1 |
+----+------------------+--------+
and your table recharge
+----+------------------+---------+------------+--------+--------+------------+
| id | recharge_type_id | user_id | payment_id | amount | status | time |
+----+------------------+---------+------------+--------+--------+------------+
| 1 | 1 | 1 | 1 | 2.00 | 1 | 2019-03-05 |
| 2 | 2 | 1 | 2 | 3.00 | 3 | 2019-03-05 |
| 3 | 2 | 1 | 2 | 4.00 | 4 | 2019-03-05 |
+----+------------------+---------+------------+--------+--------+------------+
With this type of construction you are pretty flexible for nearly any approach.
If you want to understand why this is a good approach, you should read
some articles about first normal form. You can find an article
here on Wikipedia.
I've got a small CRM and I'm trying to figure out the best way to designing the DB tables.
I've currently got a single table for users that got around 30 columns which I alter from time to time. Since I am storing two different information on that table (user + company information) I was thinking of splitting that table into 3 (user + company + connection between these 2) but I am also interested in keeping a copy of any changes that are being made in these rows.
So going from:
user_id | firstname | last_name | company_name | company_city | company_subject | rank | status
1 | John | Borrows | Boink INC | NY | Web dev | 1 | 1
2 | Mike | Smith | Smithin INC | OC | Laywer | 1 | 2
3 | Mary | Anton | Caffin | SJ | Moving | 2 | 1
to something like this
user_id | firstname | last_name | rank | status
1 | John | Borrows | 1 | 1
2 | Mike | Smith | 1 | 2
3 | Mary | Anton | 2 | 1
comp_id | company_name | company_city | company_subject
1 | Boink INC | NY | Web dev
2 | Smithin INC | OC | Laywer
3 | Caffin | SJ | Moving
con_id | user_id | comp_id
1 | 1 | 1
2 | 2 | 2
3 | 3 | 3
But I'm not sure how to track the changes when for example a user changes the company name or some other info on user's table etc.
Just follow the normalization rules for structuring your database tables. You will find anything you need for that by just searching for database normalization.
Regarding your "update-history" you could add a Timestamp to your datasets and/or a separate boolean field "outdated" to be able to filter out the latest information.
Would be the simplest solution that comes into my mind.
(Sorry, my english isn't very good)
Hi, I am trying to learn how to work with junction tables in MySQL and I can't figure how to do something. I know the basics of MySQL but I have never worked with "JOIN".
In this test project, I would like to be able to show on a page the app of a given category (you click on "Games", only the apps that are in the "Games" category will be displayed on the page). I would like to know what the SQL request should look like.
Second question, let's say that an App could fit 2 different categories, how can I manage to give that app 2 different Category_ID in my database ?
Here is what my Database looks like at the moment :
Table name: APPS
+------------+-------------------+
| App_ID (pk)| App_Name |
+------------+-------------------+
| 1 | Weather Network |
| 2 | Is it sunny 2.0 |
| 3 | The Weather App |
| 4 | Zelda |
| 5 | Megaman |
| 6 | Doom 3 |
+------------+-------------------+
Table name : CATEGORY
+-----------------+-----------------+
| Category_ID (pk)| Category_Name |
+-----------------+-----------------+
| 1 | Games |
| 2 | Weather |
+-----------------+-----------------+
Table name : JUNCTION_APP_CATEGORY
+----------------+--------------------+
| APP_ID (pk) | Category_ID (pk) |
+----------------+--------------------+
| 1 | 2 |
| 2 | 2 |
| 3 | 2 |
| 4 | 1 |
| 5 | 1 |
| 6 | 1 |
+----------------+--------------------+
For your first question, the answer is
SELECT a.*, c.*
FROM APPS a, CATEGORY c, JUNCTION_APP_CATEGORY ac
WHERE a.App_ID=ac.APP_ID
AND c.Category_ID=ac.Category_ID
AND ac.Category_ID=<category_id for category "Games">
For your second question, you can use both APP_ID and Categor_ID as the primary key of table JUNCTION_APP_CATEGORY(note NOT TWO pks, but use the two columns together as ONE pk). So that you can put data like this:
+----------------+--------------------+
| APP_ID (pk) | Category_ID (pk) |
+----------------+--------------------+
| 1 | 1 | <-- APP_ID=1 belongs to both cat 1 & 2
| 1 | 2 |
| 2 | 2 |
| 3 | 2 |
| 4 | 1 |
| 5 | 1 |
| 6 | 1 |
+----------------+--------------------+
Okay, so lets say that we have 4 columns and 3 rows of data.
|user_id|pick_1|pick_2|pick_3|
-------------------------------
|fred |C++ |java | php |
------------------------------
|eric |java |C++ | php |
------------------------------
|sam | C++ | php | java |
------------------------------
So right now, users are entering their favorite languages. The first pick(pick_1) would be the favorite programming language and the second pick (pick_2) would be the 2nd favorite programming language and etc.
How can I organize this in a way so that I can give a point value according to what columns the programming languages are. So maybe pick_1 can give 3 points, pick_2 can give 2 points and pick_3 can give 1 point.
So when you tally up the scores, C++ will have 8 points, java will have 6 points, and php will have 4 points.
That way I can give an overall ranking of what tends to be the more favorable programming language. Like so
|rank|language|points|
----------------------
| 1 | C++ | 8 |
----------------------
| 2 | java | 6 |
----------------------
| 3 | php | 4 |
----------------------
It doesn't even need to have a point system, I just couldn't think of another way to rank the languages on a scale of liked to un-liked. So if there's another way to yield the same results than please let me know. Otherwise how would I be able to do this. Preferably in just MySql. I am currently using PHP.
Thank you for reading.
You need a simpler structure
User_ID | Pick | Points
Fred c++ 3
Fred php 2
Fred java 1
This way you can do a simple sum(points) group by pick
for a SQL only solution, I would normalize your structure, and put the picks in a different table:
users: user_id; user_name
picks: pick_id; user_id; language; points;
then you would have your data in 2 tables:
| user_id | user_name |
-----------------------
| 1 | Fred |
-----------------------
| 2 | Eric |
-----------------------
| 3 | Sam |
-----------------------
| pick_id | user_id | language | points |
---------------------------------------------
| 1 | 1 | C++ | 1 |
---------------------------------------------
| 2 | 1 | Java | 2 |
---------------------------------------------
| 3 | 1 | php | 3 |
---------------------------------------------
| 4 | 2 | Java | 1 |
---------------------------------------------
| 5 | 2 | C++ | 2 |
---------------------------------------------
| 6 | 2 | php | 3 |
---------------------------------------------
| 7 | 3 | C++ | 1 |
---------------------------------------------
| 8 | 3 | Java | 2 |
---------------------------------------------
| 9 | 3 | php | 3 |
---------------------------------------------
And then use the following query to fetch the desired result:
SELECT language, SUM(points) FROM users JOIN picks ON users.user_id=picks.user_id GROUP BY language
As seen in this fiddle
This way it's also easy to add constraints so people can not vote for a language more then once, or give the same amount of votes to 2 different languages.
i have a table in following format:
id | title
---+----------------------------
1 | php jobs, usa
3 | usa, php, jobs
4 | ca, mysql developer
5 | developer
i want to get the most popular keywords in title field, please guide.
If you have a list of keywords, you can do the following:
select kw.keyword, count(*)
from t cross join
keywords kw
on concat(', ', t.title, ',') like concat(', ', kw.keyword, ',')
As others have mentioned, though, you have a non-relational database design. The keywords in the title should be stored in separate rows, rather than as a comma separated list.
If your data is small (a few hundred thousand rows or less), you can put it into Excel, use the text-to-columns function, rearrange the keywords, and create a new, better table in the database.
SELECT title 1, COUNT(*) FROM table GROUP BY title 1
EDIT
Since you've edited and presented a non-normalized table, I would recommend you normalize it.
Have a read of: http://blog.fedecarg.com/2009/02/22/mysql-split-string-function/
You need to modify your database. You should have something like this:
items
+----+---------------+
| id | title |
+----+---------------+
| 1 | something |
| 3 | another thing |
| 4 | yet another |
| 5 | one last one |
+----+---------------+
keywords
+----+-----------------+
| id | keyword |
+----+-----------------+
| 1 | php jobs |
| 2 | usa |
| 3 | php |
| 4 | jobs |
| 5 | ca |
| 6 | mysql developer |
| 7 | developer |
+----+-----------------+
items_to_keywords
+---------+------------+
| item_id | keyword_id |
+---------+------------+
| 1 | 1 |
| 1 | 2 |
| 3 | 2 |
| 3 | 3 |
| 3 | 4 |
| 4 | 5 |
| 4 | 6 |
| 5 | 7 |
+---------+------------+
Do you see the advantage? The ability to make relations is what you should be leveraging here.