Hello, I will write an application with a database connection. Subject Bd: "rental computer games." So I can not really make up the structure in my head. For example, 1 table - I decided that there would be sellers (let there be fields: last name, address and rental date), table 2 - movies (fields: genre, price and for example a short description) I would also need to make 3 tables - I thought to make a table Clients, but how would you link these 3 tables logically? I was thinking of combining the table films with the seller, but then what happens is that each movie will correspond to each movie? This is stupid, well, the truth can for example be made so that one seller corresponds to several films (one-to-many relationship), but then there will be a bunch of duplicate names in the table. I ask you to help me draw up a general scheme to present what I should do. Thank!

Closed due to the fact that the question is too general for the participants D-side , Streletz , aleksandr barakin , zRrr , Nick Volynkin ♦ Jun 3 '16 at 6:18 .

Please correct the question so that it describes the specific problem with sufficient detail to determine the appropriate answer. Do not ask a few questions at once. See “How to ask a good question?” For clarification. If the question can be reformulated according to the rules set out in the certificate , edit it .

  • And you have the same movie can not sell multiple sellers. For some reason I see many-to-many connections. If you have all the same connection (seller) to many (movies), then in the movies table add the seller ID. And if many to many, then a separate table with two fields of ID-movie ID-seller - Mike
  • @Mike and see if for example. There is a salesman Ivanov - the films of Alien, James Bond, Transformers will correspond to him. So if you make a one-to-many connection, does it mean that the last name will be repeated several times in the table? Is this permissible? Or in this case, as it is grouped or how? - M-Misha-M
  • You did not understand, you have two tables, in addition to the full name, the sellers have the ID of this seller, which is the primary key. In the table of films, in addition to the fields that are assigned to the film, you have the field ID-seller. Here sells your Ivanov with ID = 1 several films. There is only one record in sellers, in films there are a hundred films each of which costs 1 in the field of Id-seller. - Mike
  • @Mike yes yes, I had it in mind, for example, I, for example, assigned Ivanov 3 films images . is it better to display in other fields? I just still have the task of normalizing, so I ask, I'm sorry to bother you - M-Misha-M
  • one
    Well, the normalization is in the database, and on the output you unfold into how it should look. If you just need a list of all the films, then everything is clear there, films and names are nearby. If you need movies for a specific seller and write in the title "Films Ivanov" and a list of titles. Do you want to write them next to the last name, simply separated by a comma, collected on the client in such a list or with the help of some sort group_concat - Mike

2 answers 2

Table 1. Sellers
[Id, FIO, ...]

Table 2. Customers
[Id, FIO, ...]

Table 3. Disks (games, movies)
[Id, Title, ..., Status]

Table 4. Rent (because the wheels are for rent)
[Id, StartArendaDate, EndArendaDate, Id_Disk, Id_Client, Id_Customer]

Like that.

  • In the Аренда table, it would be still useful to add a field with the actual disc return date, so that, for example, you can find out which customers forget to return the discs on time. Well, in general, this entire lease is hardly done without any costs, so it would be necessary to keep some financial information. :) - Yaant
  • Yes, no problem ... all that is needed. I proposed a solution to the problem, and then, all that the soul wants - MaximK

Need table "Order". There you write the id of the sold discs, the id of the seller and the buyer, the date, the amount, etc.

  • Try to write more detailed answers. Explain what is the basis of your statement? - Nicolas Chabanovsky ♦