I am putting together a database which will hold information on various media items of different media types. Each media item could then be added to a media collection which could then be used to create media sliders, galleries etc.
Here is an example db
media_types
-----------
id code title
1 images Images
2 videos Videos
3 files Files
gallery_items
-------------
id gallery_id mediaTypeId mediaId
1 1 1 2
2 1 3 1
3 1 2 3
images
------
id title filename
1 X-Wing xwing.png
2 Tie Fighter tie.png
3 A-Wing awing.jpg
videos
------
id title filename
1 Hoth iceplanet.wmv
2 Bespin bespin.ogg
3 Tatooine desert.mpeg
files
-----
id title filename
1 Death Star Plans bothanx.pdf
2 Millenium Falcon Schematics yt1300.pdf
3 Rebel Alliance manifesto.doc
I would like to be able to select all items in a particular gallery with one MySql statement but at present, I can only work out how to perform it in two steps:
1) Select all items from the gallery_items table with a particular gallery id
2) Select the item details from the relevant media type table by analysing the mediaTypeId
In the example I give, the media type tables are very simple, sharing the same columns but in reality they will have different amounts of columns and different column names. A basic join statement on mediaId won't work as each media type table could share the same id.
I had thought about using a unique mediaId across all media types but this would enforce an absolute relationship between the gallery_items table and the media types tables which I would like to avoid (not all items in the media types tables will end up in a media collection). Perhaps the solution would be to create another table, media_items, which created a unique media id for each each which would then be used in each media type table? I am however weary of unnecessary table proliferation.
Any suggestions on how to best approach this design would be most appreciated.
IIWM: I would have one table of 'media types' like you have it. Then another table of media with a unique ID, media type, filename, etc. Last have a table with gallery info - unique id, media id and any other gallery info.
To make it more useful you could have a table of 'changes' that track datetime of assignments to/from a gallery for each piece of media, date it was received, sold, etc. This would track the 'lifespan' of each piece in your collection.
Related
I am pretty new to database schema design. So this may sounds trivial to experts
I am designing a app that store photo for each trip I created.
So, I have one table storing trips and one table storing some photos belonging to each trips.
So, things seems easy for designing this table . And below are my drafted schema
Trips
ID
title
created_at
Photos
ID
title
created_at
image_location
trip_id
Here is the problem:
If I would like to show the order of photos, I can make use of the attribute of created_at in Photos.
But what if one day I would like to rearrange the order of images or I inadvertently assign the photos with wrong order at the first time I add it into the trip.
What I come up with is that I try to make an column called order_no in Photos, so when there is new photos added, its order_no would be increased by one and assigned to it.
Photos
ID
title
created_at
trip_id
order_no
However, the problem is that I will have to update every order_no to keep the sequence order consistent when there is a new rearrangement
For example , I would like to rearrange the position of photo4 , the original order is like below
1 photo1
2 photo2
3 photo3
4 [photo4]
1 [photo4]
2 photo1 (order_no need to be changed from 1 to 2)
3 photo2 (order_no need to be changed from 2 to 3)
4 photo3 (order_no need to be changed from 3 to 4)
Is there a consistent way to implement this ?
Thanks
I'm in a situation where I'm in a bit of doubt of whenever I should give a shared 'like' table or split it up into two different tables.
The application will show both videos/images in a 'wall' like manner, like Facebook and many other platforms do.
If the user has already liked an image or video the like button will be colored to show that the content has already been liked.
Video table
id title desc url src
------------------------------------
1 soms thing wwww .png
Image table
id title desc src
------------------------------
1 soms thing .jpg
Options 1 two tables
Vote table video
id video_fk user_fk voted
-----------------------------------------
1 1 1 2
Vote table image
id image_fk user_fk voted
-----------------------------------------
1 1 1 2
Options 2 1 table
Vote table shared (type_fk is identifying which type it is, 1 for image 2 for video)
id content_fk user_fk type_fk voted
-------------------------------------------------
1 1 1 2 2
The problem with 2 tables is when I have to lookup whenever or not a user has liked the content (when scrolling through the wall with many results) I will have to store the results in a multidimensional array with the id and an identifier to decide which content type it is (image or video).
What would you be the better way, or even a third way?
You should keep as little tables as possible, because then you reduce amount of requests and complexity of your code.
I would even go as far as to put both videos and images into the same table called 'content', seeing how almost all of your columns are the same.
I am working on a rewrite for a registration app and starting to think about how I want to design the DB structure. I need the app to be flexible because some events offer different things. Here's a particular one:
Each event offers shirts, but not every event offers the same sizes. I figured I'd have a Shirt_Size table with all possible options and then in a form to create a new Event, they'd be able to just checkbox what shirts they want. Where would I store the particular subset of sizes for that particular event? I will need to query that to populate a drop down for the form that will be for registering for events.
I figured I could do some kind of comma-separated column for the Event model that is different value IDs from Shirt_Sizes? But I've been reading that it's bad to do that, so I'm not sure how this is normally handled. Thanks!
You can create a third table that has a column for event_id and shirt_size_id and populate it as necessary. Say event1 only has small and medium shirts, you would add two rows to the table.
id event_id shirt_size_id
1 1 1
2 1 2
And if the 2nd event had small medium and large shirts, add 3 rows to the new table.
id event_id shirt_size_id
3 2 1
4 2 2
5 2 3
Then when you query for data to populate the drop down, you can join all three tables.
I am developing an evaluation system for different programs that needs a lot of flexibility. Each program will have different things to track, so I need to store what data points they want to track, and the corresponding data for the person being evaluated on the particular data point. I am guessing several tables are appropriate. Here is a general outline:
Table: accounts
- unique ID assigned to each account. We'll call this 'aid'
Table: users
- each user with unique ID.
Table: evaluation
- each program will enter in the metrics they want to track into this table (i.e attendance)
- column 'aid' will correspond to 'aid' in account table
Table: evaluation_data
- data (i.e attendance) entered into this database
- column 'aid' will correspond to 'aid' in account table
- column 'uid' will correspond to 'uid' in user table
The input form for evaluation_data will be generated from what's in the evaluation table.
This is the only logical way I can think of doing this. Some of these tables will be growing quite large over time. Is this the most optimal way of doing this?
I'm a little confused about how accounts, users and programs all relate to each other and whether or not account and program are the same thing and that you used the terms interchangeably. I'm going to use different terms which are just easier for me to understand.
Say you have a website that allows freelancers to keep track of different projects and they can create their own data to track. (Hope you see the similarity)
Tables...
freelancers
id title etc
projects
id freelancer_id title description etc
data_options
id freelancer_id title
You can even add other columns like data_type and give options like URL, email, text, date, etc which can be used for validation or to help format the input form.
example data:
1 5 Status
2 5 Budget
3 5 Customer
4 99 Job Type
5 99 Deadline
6 102 Price
7 102 Status
8 102 Due By
This display 3 different freelancers tracking data, freelancers with the id's 5, 99, and 102. Deadline and Due By are essentially the same but freelancers can call these whatever they want.
data_values
id project_id option_id option_value
a column freelancer_id as you would be able to to a join and get the freelancer_id from either the project_id or the option_id
example data:
1000 1 2 $250
1001 1 1 Completed
1002 1 3 Martha Hayes
This is only showing information freelancer with the id 5 has input because option_id's 1-3 belong to that user.
Ok, I have 5 tables which I need to pull information from based on one variable.
gameinfo
id | name | platforminfoid
gamerinfo
id | name | contact | tag
platforminfo
id | name | abbreviation
rosterinfo
id | name | gameinfoid
rosters
id | gamerinfoid | rosterinfoid
The 1 variable would be gamerinfo.id, which would then pull all relevant data from gamerinfo, which would pull all relevant data from rosters, which would pull all relevant data from rosterinfo, which would pull all relevant data from gameinfo, which would then pull all relevant data from platforminfo.
Basically it breaks down like this:
gamerinfo contains the gamers basic
information.
rosterinfo contains basic information about the rosters
(ie name and the game the roster is
aimed towards)
rosters contains the actual link from the gamer to the
different rosters (gamers can be on
multiple rosters)
gameinfo contains basic information about the games (ie
name and platform)
platform info contains information about the
different platforms the games are
played on (it is possible for a game
to be played on multiple platforms)
I am pretty new to SQL queries involving JOINs and UNIONs and such, usually I would just break it up into multiple queries but I thought there has to be a better way, so after looking around the net, I couldn't find (or maybe I just couldn't understand what I was looking at) what I was looking for. If anyone can point me in the right direction I would be most grateful.
There is nothing wrong with querying the required data step-by-step. If you use JOINs in your SQL over 5 tables, we sure to have useful indexes on all important columns. Also, this could create a lot of duplicate data:
Imagine this: You need 1 record from gamerinfo, maybe 3 of gameinfo, 4 ouf of rosters and both 3 out of the remaining two tables. This would give you a result of 1*3*4*3*3 = 108 records, which will look like this:
ID Col2 Col3
1 1 1
1 1 2
1 1 3
1 2 1
... ... ...
You can see that you would fetch the ID 108 times, even if you only need it once. So my advice would be to stick with mostly single, simple queries to get the data you need.
There is no need for UNION just multiple JOINs should do the work
SELECT gameinfo.id AS g_id, gameinfo.name AS g_name, platforminfoid.name AS p_name, platforminfoid.abbreviation AS p_abb, rosterinfo.name AS r_name
FROM gameinfo
LEFT JOIN platforminfo ON gameinfo.platforminfoid = platforminfo.id
LEFT JOIN rosters ON rosters.gameinfoid = gameinfo.id
LEFT JOIN rosterinfo ON rosterinfo.id = rosters.rosterinfoid
WHERE gameinfo.id = XXXX
this should pull all info about game based on game id
indexing on all id(s) gameinfoid, platformid, rosterinfoid will help on performance