Prawidłowa struktura danych MS SQL?

Część,
Robię projekt aplikacji webowej do prowadzenia statystyk, analiz plikarskich, praca docelowo na inzynierke. Krótka charakterystyka:
-4 topowe ligi EU
-statystki wybranych kryteriów tj. gole, kartki, rzuty rożne
-aplikacja ma się sama aktualizować po rozegranej kolejce
-uzytkownik może wybierać interesujące statystyki i okres wstecz do analizy, dodawać komentarz, analizę

Pomysł jak pomysł ale czasu mało i już nie mam odwrotu.

(dbo.Numer_kolejki jeden do wielu .dbo.Mecze)

Pytanie 1
Przerabiałem już te tabelki ze 3 razy, widzicie jakieś rażące błędy w strukturze, relacjach?

Pytanie 2
Pomysłem na pobieranie danych ze strony do bazy a propos statystyk był skrypt PHP z wykorzystaniem biblioteki curl i komend mb_str, ale już raczej się z tym nie wyrobie więc mogę go jedynie opisać projektowo.
Myślicie że to przejdzie na pracę dyplomową? Czy ktoś coś wie na jakiej zasadzie działają takie strony jak np. Meczyki.pl z których ja korzystam i chciałem wykorzystać do PHP?

Jak bym nie robił oddzielnych tabelek na Rzuty rozne i Wyniki itp tylko dodał tableke eventów z typem eventa. Nie masz wiązania miedzy kolejka a mieczem.

-aplikacja ma się sama aktualizować po rozegranej kolejce

Czyli jak? Automagicznie ma generować dane. Sa api, również darmowe co udostępniają takie dane.

A czy przejdzie na pracę dyplomową to musisz pytać promotora, a nie nas.

@R1D3Rekk:

tabele w rodzaju wynik A : B będa zmuszały do szukania na dwa sposoby, bo może interesująca nas drużyna jest 'A' albo 'B'.
Bardziej skomplikowana struktura gdy to będą dwie połówki wyniku w dwóch wierszach
mecz_id, druzynaA, liczba
mecz_id, druzynaB, liczba
da łatwiejsze przeszukiwania
Ale nic na świecie nie jest idealne, moja propozycja nie gwarantuje, że o tym samym meczu zawsze będziemy mówiąc w ten sam sposób, zależnie od losowych spraw A będzie Wisłą a B Cracovia, albo na odwrót, musiałbyś mieć dodatkową zasadę, która to stabilizuje.

Mecz w mojej koncepcji nie musi mieć id_wyniku (w twojej zresztą też), wystarczy że wynik / dwa wyniki mają klucz do meczu.

Co więcej, "mój" połówkowy Wynik mozę mieć dodatkowe informacje: kartki, karne, rzuty rożne na obie strony, co chcesz ... Głosno myślę, to zaczyna mieć zalety. Wpis z meczem wystarczy że pojawi się na etapie planowania (nie ma NIC o wyniku), i nie musi być aktualizowany - a Wynik (dwa Wyniki) są insertowane po meczu i też nigdy się nie zmieniają (masz bogatszą tabelę Wynik, ale wiele tabel skreślasz)

Zacząłeś rysowac połączenia relacji, ale potem je zarzuciłęś?
Rysunek jest niedokończony, choć początek był dobry

Warto powiedzieć, że sucha struktura bazy to nie wszystko co do projektu, mam na myśli pewne konwencje, których schemat nie wyrazi, i trzeba opisac scenariusze.

Dzięki za odpowiedzi, jak wrócę do domu bardziej je przeanalizuje i się ustosunkuje, na szybko nie zależy mi żeby tabel było mniej i żeby to było lepiej zoptymalizowane bo potrzebuje objętosciowo dużo do opisywanie w mojej pracy(wiem że bolą was pewnie takie rzeczy ale sorki)

Co relacji to brakuje tylko chyba tego co napisałem w opisie, (dbo.Numer_kolejki jeden do wielu .dbo.Mecze) i przypomniał kolega wyżej.

Drużyna a oznaczać miała dru gospodarzy bo to istotne w moim zamyśle (zawsze jest z lewej strony wyświetlana).
Na razie dzięki, później jeszcze przeczytam na spokojnie wasze opinie.

R1D3Rekk napisał(a):

Część,
Robię projekt aplikacji webowej do prowadzenia statystyk, analiz plikarskich, praca docelowo na inzynierke. Krótka charakterystyka:
-4 topowe ligi EU

Nie widzę w schemacie żadnej informacji o ligach.

-statystki wybranych kryteriów tj. gole, kartki, rzuty rożne

Czy dla użytkownika ma znaczenie kolor kartki? Jak na obronie odpowiesz, dlaczego danych o wyniku, liczbie rzutów rożnych i kartek nie masz w tabeli Mecze? Bo raczej nie "miałbym za mało rzeczy do opisania".

-aplikacja ma się sama aktualizować po rozegranej kolejce

Nie dotyczy schematu.

-uzytkownik może wybierać interesujące statystyki i okres wstecz do analizy, dodawać komentarz, analizę

Nie widzę, gdzie te komentarze będą zapisane. Jaka ma być relacja między wyborem interesujących statystyk, a analizą? W ogóle ma być jeden użytkownik? Bo znów, w projekcie bazy ani słowa o nim/nich.

Tak ogólnie mam wrażenie, że projekt tej bazy jest od d**y strony.
Wygląda to z grubsza tak. "Mam zrobić projekt związany z piłką nożną i statystykami. Jakie mam informacje o meczach? No są drużyny, mecze, kartki, rzuty rożne, sezony - to powrzucam to w tabelki, z grubsza połączę, jakoś się je wypełni i zrobi selecty i git będzie."

Powinno to być raczej:
"Mam zrobić projekt związany z piłką nożną i statystykami. Rozpisuję z perspektywy użytkownika funkcjonalności, które mam dostarczyć. Statystyka taka, statystyka śmaka, zestawienie danych takie, zestawienie śmakie. Wtedy wiem, jakich informacji dokładnie potrzebuję i co mam trzymać w bazie. Wiem, czy istotne są dla mnie kartki jako takie, czy może podział żółte/czerwone, a może też ważna jest minuta, a może jaki gracz dostał. Z tego wyprowadzam tabele, relacje.".

Dobrze jest też pomyśleć o rozszerzalności bazy, tj. co zrobić, jak zmienią się kryteria biznesowe. Zastanów się, jak bardzo musiałby zmienić się schemat bazy przy zmianie wymagań, tj:

• wie Pan, fajna aplikacja, ale drużyna zmienia nazwę, doszedł nam sponsor, wcześniej to był Huragan Łęczyca, a teraz jest Huragan Katalizatory Nowak i Syn Łęczyca.
• wie Pan, fajna aplikacja, mamy statystyki z meczy ligowych, ale chcielibyśmy trzymać informacje o meczach pucharowych.

Trochę pozmieniałem strukturę tabel

Nie widzę, gdzie te komentarze będą zapisane. Jaka ma być relacja między wyborem interesujących statystyk, a analizą? W ogóle ma być jeden użytkownik? Bo znów, w projekcie bazy ani słowa o nim/nich.

W sumie zamysł był taki, że informacje co do statystyk z meczy miały być jako pomoc w analizie a nie odnośnik. Nie bardzo wiem jak rozwiązać ten problem, dodać jakąś tabele do tych analiz czy zrobić kolejną bazę danych co do tych komentarzy?

Trochę mnie przerasta ta praca czasu mało pomocy ze strony uczelni jeszcze mniej a coraz więcej problemów.

Co do bazy to już chyba trochę lepiej to wygląda ale pewnie jeszcze można lepiej to rozpisać. Widzicie może jakieś większe błędy?
I pytanko co do auto inkrementacji, powinienem dodawać do wszystkich standardowy klucz PRIMARY KEY IDENTITY(1,1), czy dodawać jakieś inne wartości początkowe i inkrementacje?

W sumie zamysł był taki, że informacje co do statystyk z meczy miały być jako pomoc w analizie a nie odnośnik. Nie bardzo wiem jak rozwiązać ten problem, dodać jakąś tabele do tych analiz czy zrobić kolejną bazę danych co do tych komentarzy?>

Po co oddzielna baza?

Trochę mnie przerasta ta praca czasu mało pomocy ze strony uczelni jeszcze mniej a coraz więcej problemów.

Ale co ma Ci uczelnia zapewnić? Projekt bazy? To nie jest projekt na pierwszym roku, a podsumowanie niemałego elementu edukacji.

Co do bazy to już chyba trochę lepiej to wygląda ale pewnie jeszcze można lepiej to rozpisać. Widzicie może jakieś większe błędy?

Moim zdaniem w niektórych masz głupio zrobione klucze i nie rozumiesz ich sensu.
Czym różni się relacja Drużyny-Stadiony od Statystyki_druzyna-Mecze?
W jednym przypadku masz klucz obcy w jednej tabeli, w drugim masz "wzajemne" klucze. Dlaczego?
To byłoby moim zdaniem idealne pytanie wyciągająco-pogrążające na obronie.

Albo inaczej. Na przykładzie Statystyki_druzyna i Mecze.
Powiedzmy, że masz paczkę danych o nowym meczu, pomińmy IDStatystyki_zawodnik
Wiesz, że:

• IDdruzyny_A = 1, IDdruzyny_B=2
• mecz grany 10.01.2022
• drużyna A (rzuty_rozne = 1, strzały = 2, celne = 0, faule = 5)
• drużyna B (rzuty_rozne = 3, strzały = 0, celne = 0, faule = 0)

Jakie inserty zrobisz? Bo to powinno dać Ci odpowiedź na pytanie, dlaczego taka relacja śmierdzi, choć można znaleźć uzasadnienie dla jej istnienia.

Ok, wprowadziłem znowu sporo zmian liczę, że teraz jest to bardziej przystępne, co myślicie?

@R1D3Rekk:

Zakładam, ze w wyobraźni ciągle kontrolujesz ... np wyobrażasz sobie kwerendę

"znajdź wszystkie bramki w sezonie, które strzeliła Wisła"

Bo jeśli nie postawiłeś sobie choćby w wyobraźni takiego pytania ...

Statystyki_druzyna do poprawki, po co strzaly_A strzaly_b itd ? Jak ta statystyka jest pod kątem jednej druzyny...

Jak to ma działać na kilka sezonów to temat transferów masz zupełnie nieogarnięty ;)

R1D3Rekk napisał(a):

Ok, wprowadziłem znowu sporo zmian liczę, że teraz jest to bardziej przystępne, co myślicie?

Lepiej.
Statystyki_druzyna. Dla jednego meczu będziesz miał jeden, czy dwa wpisy w tej tabeli?
Jeśli jeden (na co wskazują pola costam_A, costam_B), to co wstawiasz w IDdruzyna?
Jeśli dwa (czyli statystyki danego zespołu w meczu, na co wskazuje nazwa tabeli i IDdruzyna), to po co pola costam_A, costam_B?

-uzytkownik może wybierać interesujące statystyki i okres wstecz do analizy, dodawać komentarz, analizę

Według powyższego do czego użytkownik ma dodawać komentarz/analizę? Do jednego meczu? Bo tak wynika z tabel, które dodałeś.
Spójrz na to od strony użytkownika. Wchodzi na stronę, powiedzmy, że się loguje (coś z hasłami by się tu przydało) i co? Do czego ma dodawać te komentarze?
Per mecz? Wtedy tabelki, które masz, są ok.
Per "interesujące statystyki"? No powiązanie komentarza z IDMecz jest słabe (bo co jeśli interesującą statystyką jest ilość żółtych kartek, które dostają zawodnicy w wieku powyżej 30 lat w latach 2002-2010?). Swoją drogą pole wiek u zawodnika w kontekście trzymania danych o kilku sezonach? Ten wiek, to w którym sezonie tak dokładnie?

Uwaga ogólniejsza. Baza to tylko narzędzie. Na pierwszym miejscu powinieneś postawić to, co aplikacja powinna robić. W przypadku jednoosobowego projektu powinieneś móc rozrysować każde okienko i opisać, co użytkownik będzie mógł zrobić tu, co tam. Z tego wynika, jakie informacje powinieneś przechowywać, w jakich powiązaniach. Wtedy stawiasz sobie pytanie, czy trzymać to w bazie SQLowej, czy może w innej postaci.

Jeśli by to działało w "happy patch" od strony użytkownika - inżynierkę oceniałbym na 3.0.
A skala w górę byłaby za inne aspekty.
Za spojrzenie na bazę w kontekście rozszerzalności wymagań (to, o czym pisałem wcześniej "No fajnie, chcielibyśmy dodać...").
Za spojrzenie na front w kontekście bezpieczeństwa (jak przechowywane są hasła, gdzie i jakie zabezpieczenia przeciwko najprostszym SQLInjection są).
Za spojrzenie na strukturę kodu w kontekście "no dobra, chcemy przejść na inny silnik bazy". Do zaorania połowa projektu, czy może jeden fragment z connectorem?

Oki dodaje kolejną przerobioną strukturę,

Co się zmieniło:

• usunąłem tabele Sezon, dodałem kolumnę do Numer_kolejki
• dodałem tabele Gole- w sumie istotne w której minucie była bramka, typ mam na myśli(z akcji, karny, wolny)

Jak to ma działać na kilka sezonów to temat transferów masz zupełnie nieogarnięty ;)

• dodałem tabele transfery

Statystyki_druzyna. Dla jednego meczu będziesz miał jeden, czy dwa wpisy w tej tabeli?
Jeśli jeden (na co wskazują pola costam_A, costam_B), to co wstawiasz w IDdruzyna?
Jeśli dwa (czyli statystyki danego zespołu w meczu, na co wskazuje nazwa tabeli i IDdruzyna), to po co pola costam_A, costam_B?

• do statystyki_druzyna dodałem drużyny A i B, ale chyba pomieszałem bo coś mi tu nie pasuje
połączenia IDstatystyki_druzyna do A i do B z tabeli mecze, nie wiem czy dobrze widać

Według powyższego do czego użytkownik ma dodawać komentarz/analizę? Do jednego meczu?

Dokładnie taki jest zamysł, że nawet nie musi korzystać z tych statystyk, po prostu może wyrazić swoją opinie typu: Drużyna A win

Zakładam, ze w wyobraźni ciągle kontrolujesz ... np wyobrażasz sobie kwerendę

"znajdź wszystkie bramki w sezonie, które strzeliła Wisła"

Bo jeśli nie postawiłeś sobie choćby w wyobraźni takiego pytania ...

Obawiam się, że mój brak doświadczenia przyczyni się do tego, że dopiero potem będę miał z tym problemy...

Jak to ma działać na kilka sezonów to temat transferów masz zupełnie nieogarnięty ;)

• dodałem tabele transfery

Może tamta uwaga była zbyt skrótowa, ale "temat transferów masz zupełnie nieogarnięty" = "trzymając drużynę zawodnika w Zawodnicy.IDdruzyna nie masz opcji uwzględniania tego, że w różnym momencie zawodnik bywał w różnych drużynach, a to wpływa na statystyki, których można chcieć". Co da Ci tabela, którą stworzyłeś? W jakich widokach użytkownika się przyda? W jakich statystykach? Jeśli nie masz odpowiedzi na te pytania - tabela jest zbędna.

Statystyki_druzyna. Dla jednego meczu będziesz miał jeden, czy dwa wpisy w tej tabeli?
Jeśli jeden (na co wskazują pola costam_A, costam_B), to co wstawiasz w IDdruzyna?
Jeśli dwa (czyli statystyki danego zespołu w meczu, na co wskazuje nazwa tabeli i IDdruzyna), to po co pola costam_A, costam_B?

• do statystyki_druzyna dodałem drużyny A i B, ale chyba pomieszałem bo coś mi tu nie pasuje
połączenia IDstatystyki_druzyna do A i do B z tabeli mecze, nie wiem czy dobrze widać

Ale wiesz, że nie odpowiedziałeś na pytanie? Pytanie było proste, jeden rekord czy dwa. A piszesz o tym, że dodałeś i coś pomieszałeś i coś nie pasuje.

W ramach odnoszenia się do samego projektu bazy to będzie prawdopodobnie mój ostatni post.
Moim zdaniem w większości jest ok. Użyteczność tabeli transfery w obecnej postaci jest wątpliwa, tabelę Statystyki_druzyna masz głupią.
Ale na pierwszą iterację - może być. Sugeruję - zacznij to kodzić jak najszybciej.
Rób bazę, rób front. Próbuj zasilać to danymi z jakiegoś zewnętrznego API. Wtedy zobaczysz na własnej skórze, dlaczego niektóre rzeczy masz zrobione głupawo. I poprawisz. Normalna rzecz.

Dodałem do Tabeli Zawodnicy ID_sezon, nie jest to rozwiązanie problemu ale daje już więcej możliwości, zmieniłem też Statystyki_druzyna i zaczynam w końcu ruszać z miejsca.
Tak jak napisałeś @Los Bomberos z czasem wyjdzie co jeszcze musze poprawić, dzięki za pomoc :)