Przechowywanie danych jako string w kolumnie, a wydajność zapytań i optymalizacja rozmiaru bazy

Cześć,

mam takie pytanko. Każdego dnia gromadzę dane w tabeli, które wykorzystuje potem do wyświetlania statystyk w dashboard.
Mam kilka takich tabel, które w ciągu roku na pewno będą miały ponad 300 rekordów dla każdego użytkownika, a każdy rekord zawiera datę, swoje id, inne id i nową wartość typu int.

Zastanawiam się, czy może istnieje jakiś lepszy sposób jak to ograć, bo tak sobie myślę że jak będę miał 1000 użytkowników i każdy z nich w ciągu roku wygeneruje 365 rekordów w tabeli to daje 365 000 rekordów.

A co jeśli w tej tabeli zamiast wrzucać każdego dnia nowy rekord do bazy trzymać tylko jeden dla użytkownika, a w nim kolumnę która przechowywała będzie stringa z jsonem. W tedy będę miał tylko 1000 rekordów, no ale wiadomo że rozmiar kolumny będzie duży, no i może ewentualnie jakieś problemy z query po te dane bo zawsze będę musiał wszystkie wyciągać.
Wtedy ta kolumna agregujaca dane moglaby wygladac jakos tak [{ "data": 12.12.2022, "wartosc": "1" }, { "data": 13.12.2022, "wartosc": "2" }] itd

To co roku się zeruje więc nie będzie rosło i rosło.

Tak jak mówię to dane tylko albo może i aż do wyświetlania statystyk są więc zastanawiam się czy może jest jakaś lepsza opcja dla tego typu danych.

Co o tym myślicie? Czy taka duża ilość rekordów w bazie to jakiś problem? Chodzi mi głównie o rozmiar bazy. Bo nie mówimy tu o korporacji a o mojej aplikacji która sobie gdzies tam dziala na serwerze.

Baza której używam to postgresql i ef core

Z góry dzięki za pomoc

Na czym stoi ta baza? Jak nie na Commodore 64 to 365 000 to nawet nie zauważy, chyba że masz całkiem spapraną strukturę u zapytania.

Po pierwsze, jak napisał @S4t - jeśli nie będzie to stało na programatorze do pralki Amica, a do tego będzie to jakiś "prawdziwy" SQL, a nie silnik uproszczony typu SQLite, to taka ilość jest naprawdę malutką. Także tym się nie przejmuj, to co chcesz zrobić to jest tzw. premature optimalization - czyli rozwiązywanie na zapas problemów, które prawdopodobnie się w ogóle nie pojawią.

A po drugie - nie podałeś co ten daszbord będzie potrzebować. Czy chcesz wszystkie 300 rekordów wyświetlać w tabelce? A może jakoś uśredniać/obliczać jakieś statystyki? Bez tego ciężko coś doradzić, ale może lepszą opcją by było np. codzienne przeliczanie jakiejś średniej/ustalanie innych statystyk podczas dodawania kolejnego wpisu. I potem, jak się ma ten panel wyświetlić, to do pobrania i wyświetlenia miałbyś jedyną czy góra kilka pozycji, a nie całość z ostatniego roku.

możesz te dane partycjonować per user albo per data (rok np.) albo po obu.

Ta tabela + index po datach, który strzelam, że potencjalnie by kiedyś Ci się przydał będzie miała z 15MB przy 1000 użytkownikach. 15GB przy 1 mln userach. Podejrzewam, że dane w innej/innych tabelkach będą rosły szybciej niż wspomniana tabelka. Te pozostałe tabele, w dalekiej przyszłości, jak zaczniesz podbijać świat, urosną na tyle / narobią sobie tyle skomplikowanych relacji, że będziesz je musiał hostować na osobnych maszynach (+ duplikować dane wg zastosowań, żeby JOINów nie robić po stronie aplikacji xD). Wtedy i tak relacje szlag trafi, więc tabelka, o którą pytasz stanie się obsolete.

Swoją drogą, Twoja propozycja (z JSONo-podobną strukturą) na pierwszy rzut oka zajęłaby sporo więcej miejsca na dysku niż tabelka z większą liczbą rekordów, a dodatkowo pozbawiłbyś się możliwości tworzenia indexów dla tych pól; a jeszcze operacje update są kosztowniejsze niż inserty. W skrócie - same wady ;]

Tak jak podpowiedział cerrato, zamiast optymalizacji śmiesznej liczby rekordów lepiej pomyśleć o agregacji na poziomie bazy pod kątem tego dashboardu. Czyli wyodrębnienie faktów oraz wymiarów w osobnej tabeli/tabelach, z której łatwo i szybko będzie można pobrać dane potrzebne w dashboardzie.
Wtedy zaoszczędzisz na czasie potrzebnym na ciągłe odczyty i agregację danych.