I want to create a webpage where user can organize things they collect. As everyone collects something else I want to have the users create their own datamodell (with strict limitations). If two people are collection the same "things" they can share a datastructure.
My idea was to give every collection an ID and all the tables belonging to that collection will have the ID as a prefix.
Table: Collections
ID | Collection
1 | Poststamps
2 | Barbie Dolls
Table: 1_Base
ID | StampValue | StampPic
....
Table: 2_Base
ID | EAN | Pic
....
Thus I would create many tables as each user could in theory create their own collection. I could also use only one very big table and a mapping table. Example:
Table: Colleactions
ID | Collection
1 | Poststamps
2 | Barbie Dolls
Table: Mapping
fkCollection | FieldName | Mapping
1 | DoubleField1 | StampValue
1 | BlobField1 | StampPic
2 | StringField1 | EAN
2 | BlobField1 | StampPic
Table: CollectionData
fkCollection | DoubleField1 | ... | DoubleField10 | StringField1 | ... | Stringfield10 | BlobField1 | ...
1 | 30 | | | | | | ... |
2 | | | | 21312412414 | | | ... |
Any other ideas?
Thanks for your help!
From what I can see, your second way of attempting this is going to be the easiest way... your queries will be ten fold simpler to handle, and you wouldn't need to programmably create tables on the fly... so my suggestion would be to modify your second idea slightly... Just to clarify something also, A blob will slow down the query speed so I am changing the block to hold the source link to the image instead.
TABLE: Collections
ID| Collection
1 | Poststamps
2 | Barbie Dolls
Table: CollectionData
fkCollection | DataType | VALUE | FieldName |
1 | Double | 30 | StampID |
1 | String | London | StampName |
1 | ImgSrc | ../loc | StampPic |
2 | String | Ken | BarbieName |
2 | ImgSrc | ../loc | BarbiePic |
Related
I have two MySQL tables called tasks and users. All I want to do is I don't want to display the tasks that is already done by a user in his panel. Suppose the task table has about 1000 entries and there are about 50000 users. Also the users and the tasks keep increasing.
One solution I can think of, 1st is creating a separate table of task x user size.
For example:
user table
+---------+--------+-------+
| user_id | fname | lname |
+---------+--------+-------+
| 1 | John | Smith |
| 2 | Steve | Mark |
+---------+--------+-------+
task table
+---------+-------------+---------------+
| task_id | task | task_duration |
+---------+-------------+---------------+
| 1 | Do task 1 | 1 hour |
| 2 | Do task 2 | 1 hour |
+---------+-------------+---------------+
Creating a separate table called display
+------------+---------+---------+
| display_id | task_id | user_id |
+------------+---------+---------+
| 1 | 1 | 1 |
| 2 | 1 | 2 |
| 3 | 2 | 1 |
| 4 | 2 | 2 |
+------------+---------+---------+
So only listed tasks will be shown to the particular user.
The problem is that This does not look like an efficient solution. How can I design table in this scenario in an efficient way. If not what are the other ways?
Is it always better for small Many to Many relationship table while we just need to save single id of reference table in a new table as usual like:
Attributes
|Id | Name |
---------------------
| 1 | Attribute 1 |
| 2 | Attribute 2 |
Items
|Id | Name |
-----------------
| 1 | Item 1 |
| 2 | Item 2 |
ItemAttributes
|ItemId | AttributeId |
-----------------------
| 1 | 1 |
| 1 | 2 |
| 2 | 2 |
or Single column in the first table, to save referenced table records ids as CSV like:
Attributes
|Id | Name |
---------------------
| 1 | Attribute 1 |
| 2 | Attribute 2 |
Items
|Id | Name | AttributesIds |
----------------------------------
| 1 | Item 1 | 1, 2 |
| 2 | Item 2 | 1 |
For the purpose of using the DBMS's built-in functionality for joining tables, indexing columns, FK constraints, cascading updates, etc., the first method is always better.
I have multiple MYSQLI tables for multiple details and options about a touristic package.
I have package containing the main information, then I have package_option which contains unknown number of options added to the package, and there's package_images which contains the images.
I want to get all the information in one query, but it's prooving a difficult task. Let me explain.
I've used JOIN with but the problem was if the package_option had 3 options and the package_images had 6 images, the result was a 6*4 plus 1 (package) result table.
I would like a result containing all the fields, as many as they originaly are in the tables, not multiplied for each match in every table.
For example, the table I aim for looks like that:
-------------------------------------------------------------------------
| ID | name | description | price | option | image | size | explanation |
-------------------------------------------------------------------------
| 1 | test | some desc | 50 $ | opt. 1 | img1 | 30 | |
| | | | | opt. 2 | img2 | | |
| | | | | opt. 3 | img3 | | |
| | | | | | img4 | | |
| | | | | | img5 | | |
| | | | | | img6 | | |
Right now, the above table gets populated in every field, but it's multiplied, so I don't get only 6 rows, but 24.
I did a lot of JOINS, I'm not a beginer, which is even more frustrating, but it's the first time I try to do that, a select from multiple tables with different columns and unknown number of rows.
package_option and package_images looks like that:
-------------------------------------
| ID | package_id | option / image |
-------------------------------------
| 1 | 1 | opt. 1 / img 1 |
| 2 | 2 | opt. 2 / img 2 |
..... etc
so I don't know how many rows I'll have.
Thank you in advance for t
I am developing a movie database with both credits for actors and filmmakers. Currently, the actor and filmmaker credits are all together in one table because they only differ by one column (the "role_id" foreign key never gets used for filmmaker credits -- it is always NULL). Is it still best practice to keep them in one table ("movie_credits") or would it be better to separate ("actor_credits" and "filmmaker_credits")?
Here is a very basic schema I've defined, and I'm including some example data in it:
movie_credits
+----+-----------+---------+---------------+----------+
| id | talent_id | role_id | identity_id | title_id |
+----+-----------+---------+---------------+----------+
| 1 | 1 | 1 | 1 | 1 |
| 2 | 2 | 2 | 1 | 2 |
| 3 | 1 | NULL | 2 | 4 |
+----+-----------+---------+---------------+----------+
talent
+----+------------+-----------+
| id | first_name | last_name |
+----+------------+-----------+
| 1 | Clint | Eastwood |
| 2 | Sylvester | Stallone |
+----+------------+-----------+
roles
+----+---------------+
| id | name |
+----+---------------+
| 1 | Walt Kowalski |
| 2 | Rocky Balboa |
+----+---------------+
identities
+----+--------------+
| id | identity |
+----+--------------+
| 1 | actor |
| 2 | director |
| 3 | producer |
| 4 | screenwriter |
+----+--------------+
titles
+----+-----------------+
| id | name |
+----+-----------------+
| 1 | Gran Torino |
| 2 | Rocky |
| 3 | Creed |
| 4 | American Sniper |
+----+-----------------+
If you see a completely different way of structuring the data for this scenario, please let me know. I am open to any solution that may be even more efficient and scalable.
Basically, both actor and filmmaker are persons.
So they must be stored in a single table.
We must avoid null and redundancy from the database. But in this case, making the extra table will increase much overhead than the profit of removing null.
Also, you can simply assign filmmaker as the role to avoid nulls.
That is, there will be a role named filmmaker.
I would like to create a view from a lookup table and actual data. I have two questions.
How would you accomplish this?
Should I try to do it this way?
Senerio
Table Name: steps
Table structure with values:
There are other columns hence the ( ... )
| id | Name | ... |
| 1 | Step One | ... |
| 2 | Step Two | ... |
Table Name: steps_completed
Table structure with values:
| user_id | steps_id |
| 1 | 1 |
| 2 | 1 |
| 2 | 2 |
Results Wanted
View Structure and Values wanted:
| user_id | step_one | step_two |
| 1 | 1 | 0 |
| 1 | 1 | 1 |
Thanks for your help.
Sounds like you need a cross tab query. The only way I've seen it done is via a stored procedure like this: Cross Tab Query