I'm creating a movie information database but stuck at designing relational table between 1 movie with the others.
For example: Avengers is a prequel of Avengers 2, but should I store the reverse relation (sequel) in my database? And should I separated the relationship into separated table? Currently I have 3 alternative, but which is really the best practice for designing database?
Alternative 1: Two tables with pair of relationship stored inside the relation mapping
Movies: id, title, ...
Relation_maps: id, movie_id, related_movie_id, relation_text, reverse_relation_text
So, if I have 2 movies: Avengers, and Avengers 2. I'll have one relation mapping with relation_text of "prequel" and reverse relation text of "sequel"
Alternative 2: Split relation into separated table and store the reverse relationship as an id of the table itself
Movies: id, title, ...
Relation_maps: id, movie_id, related_movie_id, relation_id
Relations: id, reverse_relation_id (self-refer to id), relation_text
Relationship text, will be stored in another table with reverse relationship stored as an self-referring id. So in relations table, It'll become like this:
id | reverse_relation_id | relation_text
1 | 2 | prequel
2 | 1 | sequel
Alternative 3: Split relation into separated table and reverse relationship will be shown through conditional code
Movies: id, title, ...
Relation_maps: id, movie_id, related_movie_id, relation_id
Relations: id, relation_text
Same with alternative 2, except reverse relationship will be shown through conditinal statement in view code. If this is better, should I really split the relation text or combine it in relation_maps table?
Are there any better alternatives in terms of performance and best practice? Thanks in advance.
Maybe something like this:
Relations
id name
1 Star Wars
Relations_Detail
relation_id movie_id relation_type sequence
1 40 prequel 0
1 50 prequel 1
1 60 prequel 2
1 10 debut 3
1 20 sequel 4
1 30 sequel 5
You would have a multi-column primary key of (relation_id, movie_id).
Related
I am doing this in mySQL.
Currently I have two tables: 1. universitiestable 2. coursestable
Table 1. has list of all universities in the world.
Table 2. has all the courses list.
Universities Table has following columns:
id University_Name
1 NYU
2 Yale
3 Oxford
Courses table has following Columns:
id Course Univ_ids
1 BS 1:2
2 MS 3:1
3 Phd 1:2:3
now is this the correct approach to store data in this scenario where i need all the courses provided by each university listed in universitiestable
I myself figured out the solution.
I need to create a third table which stores the mappings.
third table will be like this with the following fields table name:university_courses
id course_id university_id
1 1 2
2 3 3
I'm developing a web application about TV shows. And i need help with the database design.
I made a list of what i need, but i can't figure out how to design it. I have the basic tables. Series, episodes, seasons etc. What i can't do is how to relate people with episodes/series. Here is my list:
There should be multiple people type. Actor/director/writer/guest etc.
I don't think creating seperate table for each type is a good idea. So there should be one people table. And i need to store the type somewhere.
A person may be in 1 or many series.
This can be done with people_serie table with foreign keys to people and series tables. But i need a way to relate a person to episodes too.
An actor may play 1 or many roles.
This can be done with person_role table.
This is where its getting complicating.
A role may be in 1 or many episodes in a serie.
A person may belong to more than one type in a serie. Ex: actor AND director
I hope i make it clear what the problem is.
Well, you're correct not to split the People table.
the first thing to do is add a Roles table, that will contain role id and role title (each column should be unique - you don't want 2 different ids for the Actor role...)
TblRoles
RoleId RoleTitle
-------------------
1 Director
2 Writer
3 Actor
Then you add a PersonToSeries table, that will hold it's own id, the person's id and the series's id.
This table will hold every person ever working on that series, being a regular staff member or a 1 episode guest.
TblPersonToSeries
PTSId PersonId SeriesId
---------------------------
1 1 1
2 3 8
3 4 7
The next table you will need is a PersonToEpisode table, that will hold the PersonToSeries id and the episode id, and the role id.
In this table you only need to keep integer ids so it's very light weight, and you will specify for each record in PersonToSeries the episodes it is relevant for.
TblPersonToEpisode
PTEPTSId RoleId
-------------------
1 2
2 3
3 1
When a person is usually the director of a series, but makes a guess appearance in an episode of that series, you can simply add 2 rows in PersonToEpisode for that PersonToEpisode with a different role id. (one for Actor and one for Director)
TblPersonToEpisode
PTEPTSId RoleId
-------------------
13 1
13 2
I have to create a DB for a game and for the active games I need to save 2 user id's from the users table.
Normally I would use the field user_id in my activegames table to have the reference, but how do I do this with 2 users the same time?
Like user_id1 and user_id2?
Keeping the CakePHP database structure along the convention?
Same question regarding the selected weapons for an active game. Just one would be weapon_id but the player can select up to 4 of them?
weapon_id1, weapon_id2, weapon_id3, weapon_id4?
What is here best practice?
I look forward to your answers!
Kind regards!
You are thinking in 1-1 relations. Try 1-n relations. A "link" table that contains two columns. First is game_id, second is player_id.
This table can have any number of rows for one game. Thus no specific number of players.
player table
id name
1 John Doe
2 jane Doe
game table
id title
1 A special game
game_players relation table
game_id player_id
1 1
1 2
You can do the same with weapons (or anything else)
I have a relatively simple database design that I will simplify here for the sake of brevity.
I have 4 tables => Products, Product_Sizes, Stores, Catalogs.
There are 6 stores and each store has it's own unique customized catalog, an assortment of different products and sizes that is chosen from the Products and Product_Sizes tables.
I am wondering how to best design the Catalogs table. My ideas are:
id store_id product_id product_size
1 1 53522 1
2 1 40299 1
3 2 43326 1
4 2 43326 2
OR
id store_id product_id product_sizes
1 1 53522 1
2 1 40299 1
3 2 43326 1,2
Each store has it's own unique (and only one) catalog, so a query to fetch all entries by store_id will result in that store's catalog.
Another approach would be to create another table of the combined products and product_size into it's each own unique table, let's call it Products.
id product_id product_size
1 1 1
2 1 2
3 1 3
4 1 4
This separate table gives me a unique id for all the possible products and their size variants. This would result in a single id per product for each Catalogs entry.
I would love to hear some critique and better suggestions as I feel this just isn't right and can't put my finger on how to better design this. Also, if we were to ever implement more than 1 catalog per store, I know this current design would cause me grief. Any feedback would greatly appreciated!!
If it were me, I would create the catalog table as an entity table, with it's own id. If that catalog only belong to one store, I would add a store_id column as a foreign key.
I would then add a catalog_products table. This would have a foreign key to the catalog table, as well as a foreign key to the products and/or product_sizes table. (If a product_size belongs to only one products table, then just the products_sizes table.)
To resolve a many-to-many relationship, we typically add a third relationship table.
a catalog has zero, one or more products (product_sizes)
a product (product_size) appears in zero, one or more catalogs
The relationship table gets us "one-to-many" relationships, which we can represent:
a catalog_product appears in exactly one catalog
a catalog contains zero, one or more catalog_product
a catalog_product is related to exactly one product
a product belongs to zero, one or more catalog_product
id store_id product_id product_size
1 1 53522 1
2 1 40299 1
3 2 43326 1
4 2 43327 2
Different product id for same product name with different sizes.
I would like to create a relational database in which there are two tables Users and products. Each item of each table can be related to many items of the second table.
My current implementation is as follows:
Two main tables-
->Users
User ID
UserInfo
->Products
Product ID
ProductInfo
Two different lookuptables
->UserToProduct
UserID
ProductID
->ProductToUSer
ProductID
UserID
Each time a relation from a user to a product is added, i just add an extra row to the first lookup table, and vice versa.
Is this the right way to do it? Are there any standard models for such scenarios that I can refer to?
You don't need two lookup tables, all you need is users_products. As far as resources, there are zillions, just google "database many to many".
UPDATE
Consider this data:
products
------------
id info
------------
1 car
2 flute
3 football
users
------------
id info
------------
10 bob
20 tim
30 manning
Now, as a simple example, let's say manning owns a football and and a car. Let's say tim owns a flute and a football. Now here's your lookup table:
users_products
----------------------
user_id product_id
----------------------
20 2
20 3
30 3
30 1
That's it. Now you can do queries like "give me all the users that have cars", or "give me all the cars that a user has", etc.
Cheers
You really don't need or want two different lookup tables. You should just have one (either of your tables, UserToProduct or ProductToUser, would be fine). The primary key of the lookup table should be a composite key consisting of both ProductID and UserID.