Storing dart throws in relation database (JSON vs multiple tables) I'm trying to model database for storing dart throw practices.
Data sent from frontend will look something like this
[
  {&quot;target_name&quot;:&quot;S13&quot;,&quot;singles&quot;:1,&quot;doubles&quot;:1, &quot;triples&quot;:1, &quot;misses&quot;:1}
  {&quot;target_name&quot;:&quot;S14&quot;,&quot;singles&quot;:5,&quot;doubles&quot;:3, &quot;triples&quot;:3, &quot;misses&quot;:4}
  {&quot;target_name&quot;:&quot;S15&quot;,&quot;singles&quot;:5,&quot;doubles&quot;:3, &quot;triples&quot;:3, &quot;misses&quot;:4}
   ... \\ from 1 to 100 rows
]

And i want to store in table/tables in SQL database.
On tables I want to make operations  (in brackets I placed how this selects would look like)
Requirement listed ordered by importance

Get short game summary,
(Select all_singles,all_doubles,all_triples,all_misses, points, datetime from SDT_GAME)
Get Game data, so i will send back data as was given (Select gamesheet_JSON from SDT_GAME)
Get Merged all games data for current user, for every target return
(SELECT COUNT(singles), COUNT(doubles), COUNT(triples), COUNT(misses) from sdt_row INNER JOIN ... GROUP BY target) 

I had 2 ideas like below (SDT_GAME2 vs SDT_GAME)

I like SDT_GAME_2 option more because of db normalization. But I'm worried that storing on average 50 rows for every game will clog db fast and make selecting(requirements 2) much slower.
Are any of these options clearly better considering my requirements?
When I data plan for a table or system, I think in terms of how much data do I realistically see being stored in 1 year, 5 years, 10 years and 20 years. I don't know how many games you expect in a given day and over a year's time, but accumulating millions of records in a single table in a year is not uncommon and definitely reasonable to support in most RDBMS. Obviously there's no concrete answer to exactly how many rows a table can hold at a given time and still be performant, because it's depend on the server hardware and database design, but again millions of rows in one table is not something to be scared of by any means. I've worked with tables with 10s of billions of rows that were performant running on servers with pretty standard hardware (8 Core CPU, 32 GB of RAM, SSD).
That being said, I think your database design is pretty good and I would definitely recommend going with SDT_GAME_2 because of the better normalization. The aggregations for all games data by user is something you should easily be able to calculate on the fly as needed (e.g. with a view or procedure) instead of storing the aggregation in a table.