一个大型数据库还是几个较小的数据库？

Question

After reading a lot about it and similar questions, I am still not clear about the following case.

I have an schema like this in one mysql database, where I store the probabilities of matches of more than 10 sports depending on the type of result (is intended for an application that shows the odds for each sport on different pages but I will never mix sports on the same page):

Design 1: a single database

SPORT
id
name

TEAM
id
sportId
name
birth

MATCHES
id
sportId
teamId_1
teamId_2
result
date

PROBABILITIES
id
matchId
type
percentage

(table Probabilities is very long, almost a billion rows, and will grow over time)

All necessary fields are correctly indexed. Then to see all the probabilities of the matches that do not have result with the football sport with id = 1 , I would make the following query:

SELECT s.name, t1.name as nameTeam1, t2.name as nameTeam2, t1.birth as birthTeam1, t2.birth as birthTeam2, m.date, p.type, p.percentage
FROM matches m
INNER JOIN team t1 ON t1.id = m.teamId_1
INNER JOIN team t2 ON t2.id = m.teamId_2
INNER JOIN sport s ON s.id = m.sportId
INNER JOIN probabilities p ON p.matchId = m.id
WHERE result IS NULL
AND s.id = 1

This database design is great because it allows me to work comfortably with ORM like Prisma. But for my team the most important thing is speed and performance .

Knowing this, is it a good idea to do it this way or would it be better to separate the tables into several databases?

Design 2: one database per sport

Database Football

TEAM
id
sportId
name
birth

MATCHES
id
teamId_1
teamId_2
date

PROBABILITIES
id
matchId
type
percentage

Database Basketball

TEAM
id
sportId
name
birth

MATCHES
id
teamId_1
teamId_2
date

PROBABILITIES
id
matchId
type
percentage

The probabilities table is much smaller, in some sports only thousands of rows.

So if, for example, I only need to take the football probabilities I make a query like this:

SELECT t1.name as nameTeam1, t2.name as nameTeam2, t1.birth as birthTeam1, t2.birth as birthTeam2, m.date, p.type, p.percentage
FROM football.matches m
INNER JOIN football.team t1 ON t1.id = m.teamId_1
INNER JOIN football.team t2 ON t2.id = m.teamId_2
INNER JOIN football.probabilities p ON p.matchId = m.id
WHERE result IS NULL

Or is there some other way to improve the speed and performance of the database such as partitioning the probabilities table when we only query the most recent rows in the database?

Answer 1

If you make one database per sport you are locking the application into that decision. If you put them all together in one you can separate them later if necessary. I doubt it will be.

But for my team the most important thing is speed and performance.

At this early stage the most important thing is getting something working so you can use it and discover what it actually needs to do. Then adapt the schema as you learn..

Your major performance problems won't come from whether you have one database or many, but more pedestrian issues of indexing, bad queries, and schema design.

To that end...

• Keep the schema simple
• Keep the schema flexible
• Consider a data warehouse

To the first, that means one database. Don't add the complication of maintaining multiple copies of the schema if you don't need to.

To the second, use schema migrations and keep the details of the schema out of the application code. An ORM is a good start, but also employ the Respository Pattern, Decorator Pattern, Service Pattern, and others to keep details of your tables from leaking out into your code. Then when it inevitably comes time to change your schema you can without having to rewrite all the code which uses it.

Your concerns can be solved with indexing and partitioning, probably partition probabilities, but without knowing your queries I can't say on what. For example, you might want to partition by the age of the match since newer matches are more interesting than old ones. It's hard to say. Fortunately partitioning can be added later.

The rest of the tables should be relatively small, partitioning by team isn't likely to help. Poor partitioning choices can even slow things down.

Finally, what might be best for performance is to separate the statsistical tables into a data warehouse optimized for big data and statistics. Do the stats there and have the application query them. This separates the runtime schema which must have low latency and benefits from being kept small, from the statistical database which is mostly reporting on pre-calculated statisitical queries.

---

Some notes on your schema.

Remove "sport" from the matches. It's redundant. Get it from the teams. Add a constraint to ensure both teams are playing the same sport.

Don't name a column date . First, it's a keyword. Second, date of what? What if there's another date associated with the match? Third, what about the time of the match? Make it specific: scheduled_at . Use a timestamp type.

Result should be it's own table. You're going to want to store a lot of information about the result of the match.

Answer 2

In MySQL, a "DATABASE" is a very lightweight thing. It makes virtually no difference to MySQL and queries as to whether you have one db or two. Or 20.

You might need a little bit of syntax to handle JOINs:

One db:

USE db;
SELECT a.x, b.y
    FROM a
    JOIN b ON ...;

Two dbs:

USE db;
SELECT a.x, b.y
    FROM db1.a AS a
    JOIN db2.b AS b  ON ...;

The performance of those two is the same.

Bottom Line: Do what feels good to you, the developer.