Home/ Questions/Q 9089037
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-16T22:02:52+00:00

I am creating a database and this is my first time that I work

  • 0

I am creating a database and this is my first time that I work with them.

I have one question about the one to one correspondence. I am creating a table that represents a team of a certain sport.

I want that every team will have only one arena where it plays matches and every team will have its own arena.

The arena will have many attributes (name, seats, ticket price and so on) so I would create a table for them even if I have read that the best practise to create a one to one relationship would be to put all in a single table.

Because an arena and a team are two so different concepts i would divide them into two tables in a way like this:

Club
--------------------
ClubID (PK)
ClubName
.
.
.
ArenaID (FK)


Arena
--------------------
ArenaID (PK)
ClubID (FK)
ArenaName
Seats
TicketPrice

Futhermore I thought to put the ArenaID not AutoIncremental but to put it equal to the ClubID because I will create the Arena automatically when a Club will be created.
Is it reasonable?

I want to understand well this type of relationship because it will be used also on other cases (for example every team will always have also one Assistant Coach with his skills).

Thanks to all!

Edit:

@Kevin Bowersox I was only specifying how the game will be, and I thank you for your answer.

@Peter Gluck You should think the arena as an attribute of the club, but it has other own attributes and I want to separate it from the club table to organize better the database. If a club wants to “build” another arena, it simply changes the name of the actual arena and it can change number of seats and ticket price. But the “object” saved in the database will remain the same. Only some columns will be changed.

@Branko Dimitrijevic Thanks for the detailed answer. I want to ask you some questions for better understand what you said (I am starting now to use databases).
In the first example you don’t use two key for both tables that will be, alternatively, one a primary key and the other a foreign key, but you use an only key that is, at the same time, primary and foreign key, is it correct? And what is the difference between these two choices?
Then, you say that it would be better if I put all in single table if I won’t have much team, but i I hope that i will have tens (or maybe hundreds) of thousands teams. In this case is this an enough large number to split the tables? I say this because I have more than only this one to one relationship in this table, so if I put all these one to one relationships in the same table it will be very very large..

Thanks to all for your suggestions, now I will try to use the method with two tables and two different ID keys.
But I will use in other tables the method suggested by ypercube!

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I like the idea of splitting up these tables. It will make your object model work much better.

    However, in regards to:

    Futhermore I thought to put the ArenaID not AutoIncremental but to put
    it equal to the ClubID because I will create the Arena automatically
    when a Club will be created. Is it reasonable?

    I would keep the ArenaID as its own auto integer. What happens if a club switches arenas? This is just one scenario that could cause these keys to become out of sync. I have a feeling over the course of time you will be manually adjusting some of these keys using this approach. Keep your relational database, just that, RELATIONAL and do not rely upon circumstance.

    • 0