I need to design a database to store user values : for each user, there is a specific set of columns.
For instance, Jon wants to store values in a table with 2 columns : name, age.
And Paul wants to store values in a 3 columns table : fruit, color, weight.
At this point, I have 2 options.
Option 1 - Store data as text values
I would have a first table 'profiles' with the users' preferences :
+----+---------+--------+-------------+
| id | user_id | label | type |
+----+---------+--------+-------------+
| 1 | 1 | name | VARCHAR(50) |
| 2 | 1 | age | INT |
| 3 | 2 | fruit | VARCHAR(50) |
| 4 | 2 | color | VARCHAR(50) |
| 5 | 2 | weight | DOUBLE |
+----+---------+--------+-------------+
And then store the datas as text in another table :
+----+------------+--------+
| id | id_profile | value |
+----+------------+--------+
| 1 | 1 | Aron |
| 2 | 2 | 17 |
| 3 | 1 | Vince |
| 4 | 2 | 27 |
| 5 | 1 | Elena |
| 6 | 2 | 78 |
| 7 | 3 | Banana |
| 8 | 4 | Yellow |
| 9 | 5 | 124.8 |
+----+------------+--------+
After that, I would programatically create and populate a clean table.
Option 2 - One column per type
On this option, I would have a first table 'profiles2' like that :
+----+---------+--------+------+
| id | user_id | label | type |
+----+---------+--------+------+
| 1 | 1 | name | 3 |
| 2 | 1 | age | 1 |
| 3 | 2 | fruit | 3 |
| 4 | 2 | color | 3 |
| 5 | 2 | weight | 2 |
+----+---------+--------+------+
with the type corresponding of a set of type : 1=INT , 2=DOUBLE , 3=VARCHAR(50)
And a data table like that :
+----+-------------+-----------+--------------+---------------+
| id | id_profile2 | int_value | double_value | varchar_value |
+----+-------------+-----------+--------------+---------------+
| 1 | 1 | NULL | NULL | Aron |
| 2 | 2 | 17 | NULL | NULL |
| 3 | 1 | NULL | NULL | Vince |
| 4 | 2 | 27 | NULL | NULL |
| 5 | 1 | NULL | NULL | Elena |
| 6 | 2 | 78 | NULL | NULL |
| 7 | 3 | NULL | NULL | Banana |
| 8 | 4 | NULL | NULL | Yellow |
| 9 | 5 | NULL | 124.8 | NULL |
+----+-------------+-----------+--------------+---------------+
Here I have cleaner tables, but still a programmatic trick to implement to get everything in order.
The questions
Have anyone ever face this situation ?
What do you think of my 2 options ?
Is there a better solution, less tricky ?
Tx a lot!
Edit
Hi again,
My model had a bug : impossible to retrieve a "line" of information; i.e. the informations in the "values" table are not sortables.
After some wanredings around the EAV model, it showed not suitable because it's not designed to store datas, but specific infos.
Then I ended with this model :
Firt table 'labels' :
+----+------------+------+----------+
| id | profile_id | name | datatype |
+----+------------+------+----------+
| 1 | 1 | 1 | Nom |
| 2 | 1 | 1 | Age |
| 3 | 2 | 2 | Fruit |
| 4 | 2 | 2 | Couleur |
| 5 | 2 | 2 | Poids |
+----+------------+------+----------+
Then a very simple 'nodes' talbe, just to keep track of the lines of infos :
+----+------------+
| id | profile_id |
+----+------------+
| 1 | 1 |
| 2 | 1 |
| 3 | 2 |
| 4 | 2 |
+----+------------+
and a set of tables corresponding to different datatypes :
+----+---------+----------+--------+
| id | node_id | label_id | value |
+----+---------+----------+--------+
| 1 | 1 | 1 | John |
| 2 | 2 | 1 | Doe |
| 3 | 3 | 3 | Orange |
| 4 | 3 | 4 | Orange |
| 5 | 4 | 3 | Banane |
| 6 | 4 | 4 | Jaune |
+----+---------+----------+--------+
With this model, queries are ok. Data input is a bit tricky but I will manage with a clean code.
Cheers
Take a look at EAV data models.
Option 3: make two different tables.
One table is obviously for people. The other is obviously for fruit. They should be in different tables.
Why not just have a user table with name and ID, the a userValues table that has key value pairs? that was John can have key "fruit" and value "mango, and another key "tires" and value "goodyear". Bob can have key "coin" and value "penny" and key "age" and value "42". Anyone can have any value they like and you have maximum flexibility. Speed won't be great, and you'll have to cast string to values, but it's always a tradeoff.
Cheers,
Daniel
Related
I have two tables, categories and products. Categories table is a nested set model. Products table has a serial_number field that is unique. Their schema is like this :
Categories :
+----+-----------+-----+-----+-------+-------------+
| id | parent_id | lft | rgt | depth | title |
+----+-----------+-----+-----+-------+-------------+
| 1 | Null | 2 | 9 | 0 | Cloth |
| 2 | 1 | 3 | 6 | 1 | Men's |
| 3 | 2 | 4 | 5 | 2 | Suits |
| 4 | 1 | 7 | 8 | 1 | Women's |
| 5 | Null | 10 | 13 | 0 | Electronics |
| 6 | 5 | 11 | 12 | 1 | TVs |
+----+-----------+-----+-----+-------+-------------+
Products :
+-------------+---------------+
| category_id | serial_number |
+-------------+---------------+
| 3 | 5461354631 |
| 3 | 4521516545 |
| 4 | 8513453217 |
| 6 | 1235624165 |
+-------------+---------------+
What I want is to create a view to show all serial_numbers with their category path :
+---------------+-------------------+
| serial_number | path |
+---------------+-------------------+
| 5461354631 | Cloth/Men's/Suits |
| 4521516545 | Cloth/Men's/Suits |
| 8513453217 | Cloth/Women's |
| 1235624165 | Electronics/TVs |
+---------------+-------------------+
What is the best query to generate this view?
I have have here an example table.incident table
+-------------+----------------------+
| incident_id | incident_description |
+-------------+----------------------+
| 1 | Accident |
| 2 | Homicide |
| 3 | Theft |
+-------------+----------------------+
incident_detail table:
+--------------------+-------------+-------------+
| incident_detail_id | person_name | incident_id |
+--------------------+-------------+-------------+
| 1 | errol | 1 |
| 2 | neo | 1 |
| 3 | aj | 1 |
| 4 | mark | 2 |
| 5 | calma | 2 |
| 6 | allan | 2 |
| 7 | dave | 3 |
| 8 | paul | 3 |
+--------------------+-------------+-------------+
I am providing a grid view like view that would allow the user to remove and add items in the incident_detail table. My question is, how can i update the incident_detail table? i am ok with adding new items, but removal. I don't know. Should i empty the entire table and insert the new items that the user added. But the problem here is that the existing items that weren't removed will be deleted and inserted again.
If you don't care about the incident_detail_id column incrementing more than it needs to, you can simply delete and re-insert the records, regardless of whether you changed the details for an incident.
It makes for easier SQL code but it does mean on each edit your IDs will go up. Assuming you're auto-incrementing.
After adding detail to Homicide you'll end up with:
+--------------------+-------------+-------------+
| incident_detail_id | person_name | incident_id |
+--------------------+-------------+-------------+
| 1 | errol | 1 |
| 2 | neo | 1 |
| 3 | aj | 1 |
| 9 | mark | 2 |
| 10 | calma | 2 |
| 11 | allan | 2 |
| 12 | new | 2 |
| 7 | dave | 3 |
| 8 | paul | 3 |
+--------------------+-------------+-------------+
If you're happy with that:
DELETE FROM incident_detail WHERE incident_id = 2;
INSERT INTO incident_detail (person_name, incident_id)
VALUES
('mark', 2)
('calma', 2)
('allan', 2)
('new', 2);
Given the following two tables:
+- Members -+
| ID | Name |
+----+------+
| 1 | Bob |
| 2 | Jim |
| 3 | Judy |
etc...
This table represents the members' children. Each parent may have many or no children
+- Children -------------+-----+
| ID | ParentID | Name | Age |
+----+----------+--------+-----+
| 1 | 3 | Jeff | 4 |
| 2 | 3 | Casey | 3 |
| 3 | 1 | Steven | 10 |
| 4 | 2 | Mary | 7 |
| 5 | 1 | Esther | 8 |
| 6 | 2 | Abe | 11 |
| 7 | 3 | Paul | 6 |
etc...
I need to create a table that looks like this:
+----+------+--------+------+---------+------+--------+------+
| ID | Name | Child1 | Age1 | Child2 | Age2 | Child3 | Age3 |
+----+------+--------+------+---------+------+--------+------+
| 1 | Bob | Steven | 10 | Esther | 8 | | |
| 2 | Jim | Abe | 11 | Mary | 7 | | |
| 3 | Judy | Paul | 6 | Jeff | 4 | Casey | 3 |
+----+------+--------+------+---------+------+--------+------+
I've tried various pivot table approaches, but every one that I've seen requires a known number of rows in the second table for each row in the first table. I essentially need an unknown number of columns. A group_concat isn't going to meet my requirements.
Is this possible with MySQL or do I need to do this in the backend?
I have a table with cases, but each case could have filled different parameters. So I think it is not the best solution to arrange the table such like this (e.g. - there will be much more parametters in real):
case
+----+-------+--------+-------+------------+-------+
| id | label | color | count | time | valid |
+----+-------+--------+-------+------------+-------+
| 1 | abcd | NULL | 4 | 2013-01-15 | 0 |
| 2 | efgh | NULL | NULL | 2012-12-22 | NULL |
| 3 | ijkl | fa8ee0 | NULL | NULL | 1 |
| 4 | mnop | NULL | 1 | NULL | 1 |
| ...
That contains lot of NULL values.
There is another solution, where exists related table case_params and its concept is like this:
`case` `case_params`
+----+-------+ +---------+------------+-------------+
| id | label | | case_id | param_type | param_value |
+----+-------+ +---------+------------+-------------+
| 1 | abcd | | 1 | count | 4 |
| 2 | efgh | | 1 | time | 2013-01-15 |
| 3 | ijkl | | 1 | valid | 0 |
| 4 | mnop | | 2 | time | 2012-12-22 |
| ... | 3 | color | fa8ee0 |
| ...
But there evolves the problem with column param_value - I could set it as VARCHAR(32), and make trigger which controls every parametter type if its value is correct. But I'm not sure if this is clear solution...
How would you solve problem like this? Thx
sorry when bad english, not native speaker
I´m using Mysql since quite a while and am really confused by the result of a simple LEFT JOIN on three Tables.
I have the following three tables (I created an example, to narrow it down)
a) persons
+----------+-------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+----------+-------------+------+-----+---------+----------------+
| PersonID | int(11) | NO | PRI | NULL | auto_increment |
| Name | varchar(50) | YES | | NULL | |
| Age | int(11) | YES | | NULL | |
+----------+-------------+------+-----+---------+----------------+
b) person_fav_artists
+----------------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+----------------+--------------+------+-----+---------+----------------+
| FavInterpretID | int(10) | NO | PRI | NULL | auto_increment |
| PersonID | int(10) | NO | | 0 | |
| Interpret | varchar(100) | YES | | NULL | |
+----------------+--------------+------+-----+---------+----------------+
c) person_fav_movies
+------------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+------------+--------------+------+-----+---------+----------------+
| FavMovieID | int(10) | NO | PRI | NULL | auto_increment |
| PersonID | int(10) | NO | | 0 | |
| Movie | varchar(100) | YES | | NULL | |
+------------+--------------+------+-----+---------+----------------+
My example tables are used to store an any number of artists and movies to a single person.
Weather this makes sence or not doesn´t really matter since it´s just a simple example.
Now I have the following data in the tables:
mysql> SELECT * FROM persons;
+----------+------+------+
| PersonID | Name | Age |
+----------+------+------+
| 1 | Jeff | 22 |
| 2 | Lisa | 15 |
| 3 | Jon | 30 |
+----------+------+------+
mysql> SELECT * FROM person_fav_artists;
+----------------+----------+----------------+
| FavInterpretID | PersonID | Interpret |
+----------------+----------+----------------+
| 1 | 1 | Linkin Park |
| 2 | 1 | Muse |
| 3 | 2 | Madonna |
| 4 | 2 | Katy Perry |
| 5 | 2 | Britney Spears |
| 6 | 1 | Fort Minor |
| 7 | 1 | Jay Z |
+----------------+----------+----------------+
mysql> SELECT * FROM person_fav_movies;
+------------+----------+-------------------+
| FavMovieID | PersonID | Movie |
+------------+----------+-------------------+
| 1 | 1 | American Pie 1 |
| 2 | 1 | American Pie 2 |
| 3 | 1 | American Pie 3 |
| 4 | 3 | A Game of Thrones |
| 5 | 3 | Eragon |
+------------+----------+-------------------+
Now i´m simply joining the tables with the following query:
Select * FROM persons
LEFT JOIN person_fav_artists USING (PersonID)
LEFT JOIN person_fav_movies USING (PersonID);
which returns the following result:
+----------+------+------+----------------+----------------+------------+-------------------+
| PersonID | Name | Age | FavInterpretID | Interpret | FavMovieID | Movie |
+----------+------+------+----------------+----------------+------------+-------------------+
| 1 | Jeff | 22 | 1 | Linkin Park | 1 | American Pie 1 |
| 1 | Jeff | 22 | 1 | Linkin Park | 2 | American Pie 2 |
| 1 | Jeff | 22 | 1 | Linkin Park | 3 | American Pie 3 |
| 1 | Jeff | 22 | 2 | Muse | 1 | American Pie 1 |
| 1 | Jeff | 22 | 2 | Muse | 2 | American Pie 2 |
| 1 | Jeff | 22 | 2 | Muse | 3 | American Pie 3 |
| 1 | Jeff | 22 | 6 | Fort Minor | 1 | American Pie 1 |
| 1 | Jeff | 22 | 6 | Fort Minor | 2 | American Pie 2 |
| 1 | Jeff | 22 | 6 | Fort Minor | 3 | American Pie 3 |
| 1 | Jeff | 22 | 7 | Jay Z | 1 | American Pie 1 |
| 1 | Jeff | 22 | 7 | Jay Z | 2 | American Pie 2 |
| 1 | Jeff | 22 | 7 | Jay Z | 3 | American Pie 3 |
| 2 | Lisa | 15 | 3 | Madonna | NULL | NULL |
| 2 | Lisa | 15 | 4 | Katy Perry | NULL | NULL |
| 2 | Lisa | 15 | 5 | Britney Spears | NULL | NULL |
| 3 | Jon | 30 | NULL | NULL | 4 | A Game of Thrones |
| 3 | Jon | 30 | NULL | NULL | 5 | Eragon |
+----------+------+------+----------------+----------------+------------+-------------------+
17 rows in set (0.00 sec)
So far so good.
My question is now if it´s "normal" that '12' Rows are returned for the person 'Jeff' despite the fact that he only has four 'artists' and three 'movies' assigned to him.
I think I may understand why the result is as it is, but I think it´s quite stupid to return so many Rows for so less actual data.
So is there something wrong with my query or is this behaviour on purpose?
The result I´d like to have would be like the following (only for Jeff):
+----------+------+------+----------------+----------------+------------+-------------------+
| PersonID | Name | Age | FavInterpretID | Interpret | FavMovieID | Movie |
+----------+------+------+----------------+----------------+------------+-------------------+
| 1 | Jeff | 22 | 1 | Linkin Park | 1 | American Pie 1 |
| 1 | Jeff | 22 | 2 | Muse | 2 | American Pie 2 |
| 1 | Jeff | 22 | 3 | Fort Minor | 3 | American Pie 3 |
| 1 | Jeff | 22 | 4 | Jay Z | 1 | NULL | <- 'American Pie 1/2/3' would be OK as well.
+----------+------+------+----------------+----------------+------------+-------------------+
Thanks for your help!
Nothing wrong with query or the results, it is just returning all possible combinations. One option would be to split into two separate queries if the amount of data is going to be large.
You are getting the correct result with the 12 records becuase that is the correct tuple with the way you are asking for the data. I am not sure why you are joinming these 3 tables together becuase inherently, the 2 related tables are not the same type of data. What I would suggest is that you select person & movies and then you can union person & artists, becuase your union will want the columns to be the same, i would suggest adding a type to differentiate from artists and movies and then the nice name should just be AS a string_value
This behaviour is on purpose.
Your first table has 1 columns for Jeff.
The second table has 4 columns for Jeff, so the joined table gives
1x4.
The third table has 3 columns for Jeff, so the joined table gives
1x4x3.
You now got all possible combinations.
I think it's normal since it's taking all the combinations of fav movie and fav artist. I think this is how the joining works.
Try by replacing LEFT JOIN with INNER JOIN as:
SELECT *
FROM persons
INNER JOIN person_fav_artists USING (PersonID)
INNER JOIN person_fav_movies USING (PersonID);