我应该为这些数据使用单独的表格吗？

Question

This is a backend for a project I've been working on for fun that stores user's scorecards of boxing matches. Should I have a separate table for every boxing match (about 25 columns), or should I store every boxing match in the same table and add a column denoting which boxing match the row is for?

What are good standards to practice when making this decision? I will be accessing the table by averaging all rounds of a given match and returning the average score for all users for any given round. This type of access makes me think a separate table for each match would be desirable because that way I wouldn't be searching through any unwanted matches when trying to average the scores of a certain match.

Answer 1

The standard approach is to identify each "entity" within the model.

An entity is a person, place, thing, concept or event that

1. can be uniquely identified
2. we can store information about and
3. is important to the business or enterprise

An entity is implemented as a table, with each row in the table representing a single instance of the entity.

In the example, it sounds like a "boxing match" is an entity. The next step is figure out what the unique identifier is, whether it's a single column, or a combination of columns, and plan on having a UNIQUE INDEX defined on that.

In addition to the natural key(s), we typically introduce a surrogate id column which serves as the primary key of each entity table. (I will note that there are two schools of thought on whether a surrogate key is desirable: there are those who have elected to use a natural key as the primary key and have been later burned by that decision, and then there are those that haven't yet been burned by their decision to use a natural key as the primary key.)

The ideal primary key has these characteristics:

1. simple (a single attribute which is simple native datatype, eg int)
2. unique (a value identifies only a single row, no two rows have the same value)
3. anonymous (carries no visible or hidden information)
4. immutable (once value assigned, it is not changed)

Answer 2

You should not put each match in its own table. That would mean you would need an unknown number of tables, which is an indication that you have not modeled the problem correctly.