I have a table that looks like this:
match code (key)
game code (with doubles)
and a table that looks like this:
game code (key)
tournament code (with doubles)
the two game codes are connected in a one to many relationship, and it doesn't let me insert a game code in the first table without having it in the second table, while I want it to be the opposite, where I can't insert a game code in the second table if it doesn't appear on the first table, how can I do this?
In a one-to-many relationship, the one-side is always dominant.
You would need to remove the relationship to allow data entry on the many-side, without having a corresponding key on the one-side.
Then you would need to build custom logic to check the many-side when entering data at the one-side.
Related
I'm not looking for the answer, I am just looking for some guidance or a little clarity here. I need to design a database as if I worked for redbox and I'm trying to track movies actors and directors. So I am assuming I need three different tables but I just don't understand how to "track" it. Would I create a custom ID for each movie and something that tracks where the kiosks are? Like I said, I think I can do this but I just fully understand it.
Any help is appreciated
In broad strokes here is what you need:
(Basic relational rules and strategy apply, so every table needs to have a Primary Key, and the keys will be used to relate the tables together).
movie:
One row per movie, with title, rating, year, etc.
person:
Add to that a related person table with one row for any person who might be a cast or crew member in any film.
credit:, credit_type
Now relate Movie <-> Person
Since this is a many to many relationship you need a table between the two. Typically this would be called "credit" and you need a credit_type table that will describe the credit (actor, director, writer, producer, etc).
Of course that has nothing to do with your "tracking" question. For that you would need a slew of tables:
inventory:
Here is where you have one row for every copy of a movie that exists. It should be obvious that there will be a foreign key for a movie in this table. In the real world there would be an assigned id that would then be printed out as a barcode and attached to the disk + sleeve of the physical material.
kiosk:
For every Kiosk there is a row, along with location information, which could be an address perhaps along with a note, in case there are multiple kiosks at the same location.
kiosk_bin:
For every Kiosk, you will have a 1-M bins, each with a number identifying it.
I wouldn't do it this way, but you could for simplicity add a column in kiosk_bin that would be a foreign key to the inventory table. In this way you are able to indicate that an inventory (a single copy of one particular movie) is sitting in a kiosk_bin.
member:
These are the people subscribed to the service.
member_checkout:
When a member gets a movie from a kiosk/kiosk_bin, a row gets created here, with the inventory_id, and the date, and the system would update the kiosk_bin row to remove the inventory_id and show that the bin is now empty and could accept another inventory copy.
As you can see, this is non-trivial. Database design of any relatively complicated business process is going to be more than 3 tables, I'm sorry to say.
Here's an ERD that illustrates some of the basic movie to credit relations I did for another similar question. The tables were named a bit differently but you should be able to match them up.
I have 4 tables, "Player", "Crafting", "Battling", "Gathering".
I made a relationship rule for Crafting, Battling and Gathering to share information to the Player table.
The problem is that when I go to the player table it makes me choose which other table's information to display instead of showing all 3.
How can I make a relationship so that I can view all three other tables from the player table?
It's impossible and you don't need this. You already have all relationships you need. Just create a form based on Player table with 3 subforms and link them on form, no additional code required in simple case.
Also I would recommend do not use username as primary key, use Autonumber data type instead.
I need to create a mySQL database that keeps information about vehicles. My instincts were to create one table with as many columns as I need, but then I read about the problems in doing so. After researching, I think I'm on the right track with the following structure:
Vehicles Database
Motorcycles Table
id|road|cruising|touring|
Cars Table
id|sedan|coupe|hatchback|
Colours Table
id|green|red|blue|black|silver|white|yellow|etc..
Make Table
id|ford|chevrolet|gm|toyota|bmw|etc..
Quadrant Table (1-4)
id|motorcycle|car|truck
So basically I have a table for the objects - cars, motorcycles, trucks - and then tables for the fields/properties - Colour, Make, etc. and then a table for the Quadrant the vehicle is seen in, with a value of 1-4 where each row is an instance of only one vehicle.
The problem I'm having is understanding where the primary and foreign keys need to be in order for me to be able to organize the data:
By each individual vehicle selected along with its fields
By quadrant, showing each vehicle and their respective fields
The user counting cars should be able to input the vehicle type, the field values and the quadrant it's seen in and the db gets populated - and then I need to call the data by quadrant to analyze the data.
I don't know if or how a JOIN statement will be used? How do I go about structuring this database to suit my needs?
FWIW, dba.stackexchange says basic SQL questions belong here, so I hope I'm in the right place.
Can you tell, what is your exact need for the database i.e what functionality you need.
I suggest tables like following:
1) Vehicle table:
id|type which might contain info like 1|Motorcycle, 2|Car
2) category table:
id(foreign key)|category|color which contain info like 1|touring|Black, 2|Car|Hatchback
3) Make table: (if you need to create another table)
id (foreign key to table 1)|Make
I have not understood the functionality of quadrant table but with these 3 table you can create views according to your needs and play around with it.
From my point of view:
I will create a table CarBrands, with columns Id, BrandName, Description, which will serve as a look up.
Then I will create another table Cars with Id, CarBrandId, ColorId (From Colors Table), Description, which is your table with user records.
Same with your other entities. I suggest you search about Entity Relationship Diagrams, a good way of helping you come up with a good design.
Also look at this old StackOverflow question, this will help you.
I am creating a DB for my project and I am facing a doubt regarding best practice.
My concrete case is:
I have a table that stores the floors of a building called "floor"
I have a second table that stores the buildings called "building"
I have a third table that stores the relationship between them, called building_x_floor
The problem is this 3rd table.
What should I do?
Have only two columns, one holding a FK to the PK of building and another holding an FK to the PK of floor;
Have the two columns above and a third column with a PK and control consistency with trigger, forbidding to insert a replicated touple of (idbuilding, idfloor)?
My first thought was to use the first option, but I googling around and talking I heard that it is not always the best option.
So I am asking for guidance.
I am Using MySQL 5.6.17
You don't need third table. Because there is one-to-many relationship between building and floor.
So one building has many floors and a floor belongs to one building. Don't get things complicated. Even though you need a table with composite keys, you should be careful. You need to override equals and hashCode methods.
I am still not confortable with that approach. I am not saying it is wrong or innapropriate, very far from that. I am trying to understand how the informations would be organized and how performatic it would be.
If I have a 1:* relationship, like a student may be attending to more than one subject along its university course within a semester I would Have the 3rd table with (semester, idstudent, iddiscipline).
If I try to get rid of the join table my relationship would be made with a FK inside student table or inside subject table. And it does not make sense to do that because student table is a table for a set of information related with registering the info of a person while the discipline table holds the data of a discipline, like content, hours...it is more a parametric table.
So I would need a table for the join.
I have a table called "games" in which will have games.id, games.name and games.modus fields. I know the ID should be auto increnment and integer, games.name a text value and the problem is I don't know what to make games.modus, because it will have "multiple options", another tables called "modes" will be created with modes.id and modes.name, the modes.name will have the following rows: "Singleplayer","Multiplayer","LAN","Online","LAN Co-op","Online Co-op","Offline Co-op",
and I need to be able to select multiple of those rows into the "games.modus" field. How would I achive this?
What you are describing is an N-to-N relationship. You need to model a third table so that you can have an 1-to-N and an N-to-1 relationship. N-to-N cannot be modeled otherwise, to my knowledge.
In your case, that means that you would need a table like modes_per_game which would contain a foreign key to the game id and to the mode id. If you want to make the result a bit more friendly then a simple query and form will do the job but it has to be structured with a middle table to make the links.