15000 wierszy w tabeli to dużo ? - model koncepcyjny

Chciałbym się Was poradzić, jak fizycznie (w oparciu o bazę danych) rozwiązać następujący problem..

Przechowywanie wyników każdego pojedyńczego strzału zawodnika z poszczególnych konkurencji na zawodach strzeleckich ?

W założeniu w tabeli powinny być przechowywane następujące dane (kolumny):

zawodnik_id | konkurencja_na_zawodach_id | 1_próba_wynik | 2_próba_wynik | 3_próba_wynik | etc..

I teraz nasuwa się pytanie / problem - czy można rozwiązać to w taki sposób, że każdy strzał będzie zapisywane do tabeli jako osobny wiesz?

Przykład tabeli:

zawodnik_id | konkurencja_na_zawodach_id | próba_wynik

.., ale wtedy taka tabele bardzo szybko będzie nabierała "na wadze", bo na przykład zakładacjąc :

1 zawodnik oddaje 6 strzałów. Na zawodach jest 5 konkurencji. Zawodników jest 40.

To wynik krotek z __jednych __zawodów jest równy: ((1*6) * 5) * 40 = 1200
Przyjmując, że średnio zawodów jest 12 w roku (organizowanych w ramach jednego klubu) to mamy __14400 __ wierszy w tabeli.

Jako osoba nie mająca dużego doświadczenia z bazami danych (a jak juz to mam tylko doświadczenie z minibazami) zapytuje się - czy 15000 wieszy na tabele to dużo? Czy operowanie na takiej tabeli to duże wyzwanie ? Jeśli tak to jakie rozwiązanie takiej sytuacji proponujecie? Jeśli nie to przy jakich rozmiarach tabel można się zacząć martwić? A może są jakieś "specjalne" mechanizmy, które pomagają w "selectowaniu" takiej bazy ? (partycjonowanie, indeksowanie ? (ps. tak rzuciłem te hasła bo je znam "ze słyszenia" lecz dokładnie nie wiem do czego dokładnie służą bo nie miałem okazji z nich korzystać..)

Czekam na Wasze porady :)

Najpierw:

15000 czy to dużo?

Dla Oracle/SQL Server/MySQL i innych większych baz danych to jest niczym. Potrafią one przechowywać TB rekordów i dobrze sobie z nimi radzić ( oczywiście przy stosowanych zabiegach, które nie wymagają wiedzy Einsteina ).

Czym są poszczególne konkurencje? ( nie rozumiem tego ), ale można to rozbić na minimum dwie tabele.

Piłkarz ( jego dane presonalne ) oraz Strzal_proba ( i tutaj są 3 rekordy ), potem "poszczególne konkurencje" przechowują tylko klucz obcy to tabeli Strzal_proba.

Ale te myslenie jest niczym, nie znam rzeczywistosci jaką modelujesz - być może moja dedukcja jest bezsensu. Opowiedz o tej konkurencji ( to są mecze? )

Dzięki za zainteresowanie :)
Czyli np. jeśli chciałbym wyszukać z tabeli liczącej 20.000 wierszy wszystkie wyniki (ze wszystkich zawodów/konkurencji) jednej osoby, to to nie będzie zbyt obciążające i nie będzie trwało "wieki" ? ;>

Co do twoich wątpliwości co to są za konkurencje to jakbyś niezauważył pisałem o czym jest sprawa, nawet było to pogrubione zdanie :P
" Przechowywanie wyników każdego pojedyńczego strzału zawodnika z poszczególnych konkurencji na zawodach strzeleckich ?"

Natomiast nie rozpisywałem się o całej strukturze bazy bo mi się za bardzo nie chciało Was przynudzać :P Celowo zamieściłem tylko nagłówki "teoretycznej" tabeli:

• zawodnik_id | konkurencja_na_zawodach_id | próba_wynik**

co mówi, że zawodnik_id jest kluczem obcym z tabeli zawodnicy ; konkurencja_na_zawodach_id jest kluczem obcym z tabeli konkurencja_na_zawodach..

ps. Czekam jeszcze na wypowiedzi innych osób (aby potwierdzić słowa @Ciekawskiego :) )

20k wierszy to jest nic. Jakbyś ich miał 20 milionów i wykonywał w międzyczasie sortowanie, grupowanie i funkcje agregujące a wszystko wybierał po kluczu złożonym z kilku atrybutów to dopiero mógłbyś zauważyć różnicę ;)

To jak długo będzie trwało wyszukiwanie zależy od warunków selekcji, ilości złączeń i istnienia indeksów i jeszcze paru innych rzeczy ( sprzętowych np. ). 20.000 rekordów to nie jest jakoś specjalnie dużo i zakładając indeks na określoną kolumnę tej tabeli na pewno to przyspieszysz. Musisz poczytać o partycjonowaniu danych ( fragmentacji ), indeksowaniu wtedy Ci się wszystko rozjaśni. Są pewnie ( myślę, że w MYSQL ) specjalnie usługi, które pomogą Ci określić na jaką kolumnę założyć indeks ( na taką według której najczęściej dokonuje się wyboru rekordu ).

Co do mojej nierozumności: Na początku myślałem, że chodzi o piłkę nożną :)

OK, rozumiem.. w sumie cieszy mnie ta informacja, ale...
głównie pytam o to, aby mieć argumenty przeciwko zdaniu mojego kolegi.. on uważa (chodz nie wiem na jakiej podstawie bo jego wiedza jest w oim odczuciu niczym nie poparta..), że tabela o paru tysiącach wierszy to już jak big data :P

Ogólnie chciałem się jeszcze zapytać jak dlugo mogłby trwać ( w sekundach) select na takiej tabeli o której jest mowa? Bo kumpel już coś zaczął wymyslać niestworzone rzeczy typu tworzenie X tabel w zależności od rodzaju konkurencji i zawodów.. co by dawało z 5 nowych tabel z jednych zawodów ;-| (dla mnie to jest dramat, no ale może coś takiego się praktykuje..?..)

ps. Jakby co mowa jest o mysqlu ;)

Ech, na tabeli która ma 4 miliony rekordów zapytanie:

select topic_id, count(*) from comment_topic 
group by topic_id

wykonuje mi się 1,5 sekundy, a wyciągnięcie 100000 rekordów z tej tabeli trwa ~1 sekundy (narzut pewnie wynika z tego że UI musi mi je potem wyświetlić :P)

mikajlo napisał(a):

Bo kumpel już coś zaczął wymyslać niestworzone rzeczy typu tworzenie X tabel w zależności od rodzaju konkurencji i zawodów.. co by dawało z 5 nowych tabel z jednych zawodów ;-|

To niech kolega to tak zrobi, niech napisze kod tworzący te tabele w locie, a potem robi na nich zapytania agregujące jak np. suma punktów każdej osoby we wszystkich zawodach, w których brała udział. I niech porówna czas wykonania z Twoją wersją.

(dla mnie to jest dramat, no ale może coś takiego się praktykuje..?..)

Może i się praktykuje, ale na pewno nie na trzeźwo. ;)

Jak tak bardzo zależy wam na szybkości to się zainteresujcie po prostu Not Only SQL :D . W relacyjnej bazie danych zawsze wystąpi problem optymalizacji zapytań, łatwo wydedukować czemu. Liczne złączenia nie sprzyjają szybkości wykonania, ale te bazy są najpopularniejsze, bardzo dobrze wspierane, dobrze poznane przez pokaźną grupę ludzi tych zwykłych i tych, którzy administrują ogromnymi zbiorami danych.