Nekdaj glede MySQL podatkovne baze

Nekaj me zanima pri MySQL. Torej imam naslednjo tabelo Liga s sledečimi podatki : Moštvo, št. tekem, zmage, neodločeno, porazi, dani goli (+), prejeti goli (-), točke.

Zanima me naslednje, ali bi lahko nekatere atribute kar odpravil in bi se le-ti izračunavali kar iz tabele rezultati tekem. (velja predvsem za gole (+,-), zmage, nedoločeno, porazi in točke). Pri tem pa nastane zoprno to, ker je direktno sortiranje Lige nemogoče (po točkah) in je potrebno za vsako urejanje potrebno preračunavati podatke.

Zanima me tudi ali je boljše, da po vsekem krogu samo posodobim to tabelo Liga ali je boljše da za vsak krog vnesem nove podatke in se tako spet odrešim preračunavanja podatkov za nazaj? Še posebno če se gleda "zgodovino" kluba iz tekoče sezone kot tudi za prejšnje sezone.

Posebej pa me zanima kakšna bi bila najboljša rešitev, če hočem to bazo uporabljati za več sezon. 3D podatkovna baza, kjer je ena dimenzija čas (je to sploh možno v MySQL?) ali kar za vsako sezono novo tabela? Posebej to me zanima kako se to najlepše reši?

Bi imel kdo kaj podobnega že narejeno? Ali pa da že obstaja kje na netu že narejena relacijska baza za vodenje lig? Ni nujno da ravno za nogomet, to bom že sam priredil.

Trenutno je to le teorija (še na papirju). Razčistil bi rad nekatere dileme, ker ko bo to postavljeno, bo to težje popravljat, še posebno če bodo podatki vnešeni. Je pa veliko vprašanje, kje bom podatke dobil (za nazaj, seveda).

Torej, gre za diplomsko nalogo. Spletna stran za malonogometni klub (1. Slovenska liga), kjer bi poleg novic v zvezi z (malim) nogometom imel še statistiko sezone, igralcev (še tuhtam ali le 1 ekipe, domače ali kar vseh 10 klubov) in ki bi omogočal vpogled v formo domačega (lahko tudi drugih) kluba ravno preko te statistike.

Poleg tega, tekme niso samo ligaške, so tudi pokalne in prijateljske, tako bi moral za te imeli ločeno tabelo. Ali pa tudi ne, ker bi lahko v tabeli tekme določil atribut za ligaško, pokalno ali prijateljsko tekmo.

Najbolj pa me matra, kako določit, za katero sezono se trenutno igra. Naj samo dodam nov atribut v tabelo liga? Da ne omenim, da se tudi sponzorji nekaterim ekipam menjajo tako, da je potrebno tudi v tabeli Ekipe dodati ta atribut, kot tudi igralce same. Da bi dodajal kar v tri tabele popolnoma iste podatke (sezono) se mi pa ne zdi pametno.

Trenutno imam (na papirju) tele tabele:

Moštvo.
Ekipa,
Tekma,
Tekma-Statistika
Lestvica

Predvsem, kako najlepše rešit to težavo z različnimi sezonami. Vsako leto pride nov igralec v klub, ime kluba se lahko spremeni (sponzor), tekme se tudi igrajo v določeni sezoni in tudi lestvica velja za določeno sezono.

Se kje iz mojih dveh sporočil to vidi . He, he, za to prav dobro vem. Na FOV sem imel kar tri različne predmete ki se ukvarjajo z bazami, tako da imam dovolj dobro osnovo za kaj takega.

Skoraj vsaka tabela vsebuje primarni ključ, razen v primeru ko imaš vmesno tabelo. Povezava več - več ni mogoča, ampak je potrebno narediti vmesno tabelo več - ena : ena - več. In podatke moraš obvezno normalizirat (običajno 3 normalna forma) za uporabo v podatkovni bazi.

Verjetno si sklepal iz tabele liga, kjer sem (namerno) zamenjal id_moštva (tuj ključ) kar z moštvom, pa še primarni ključ je spuščen ker se še nisem spomnil imena zanj.

Lahko pa bi rešil težavo z sezonami kar dodanim atributom id_sezone. Kar pomeni da bi imel še eno tabelo za sezone. Uh, iz tega bo nastalo cel kup povezav.

Samo tehtam, kako naj bi bilo boljše. Že res, da je samo integer, ampak ni 2004 najbolj pravilno. Če že hočem točno napisati katero sezono igrajo bi bilo bolj prav 200203 oz. 2002/03.

Kaj pa, če bi to bil sekundarni ključ v nekaterih tabelah, ki bi služil tudi določanju sezone?

> Samo tehtam, kako naj bi bilo boljše.
> Že res, da je samo integer, ampak ni 2004 najbolj pravilno.
> Če že hočem točno napisati katero sezono igrajo bi bilo bolj prav 200203 oz. 2002/03.

a je ta podatek sploh pomemben za karkoli razen izpisa?
Shraniš letnico in jo potem izpišeš takole:

SELECT CONCAT(sezona, '/', right(sezona + 1, 2)) as sezona;

Itak da lahko... 200103 je pač integer.

Primary key pa ni nič drugega kot UNIQUE INDEX (vsaj na MySQL). Torej bodo morale biti vrednosti unikatne. Kako je z drugimi podatkovnimi tipi pa ne vem... Vedno dam int in to je to..

Vidim, da imaš težave z designom baze. Mogoče ti lahko kaj pomagam. Sam delam na Oracle bazi, zato MySql-a ne poznam, pa to niti ni pomembno.
Glede ekipe.
Delitev v dve tabeli ni dobro. Kaj bos storil, ko boš potreboval še tretjo pa mogoče tudi četrto. S tega stališča tudi ni pravilna povezava med tabelama tekma in ekipa. Kaj boš vpisal v tekma.id_tuji, ko bos vpisoval podatke za domačo. Istovrstnih podatkov kot so recimo goli nikoli ne smeš deliti horizontalno, ker boš moral pri novi tabeli za neko drugo vrsto ekip v tabelo tekem horizontalno podvojiti podatke.
Tabela ekipa predstavlja sifrant glavnega nosilca podatkov in naj bo v eni tabeli. Poleg glavnih podatkov od naziva do mogoče lokacije, datuma nastanka itd, je potrebno dodati se klasifikacijske podatke, kot je recimo domača,tuja itd. Ti parametri se vedno dodajajo horizontalno v zapisu. Prednost baze je ravno v enostavnem dodajanju polj s poljubnimi podatki, seveda na pravem mestu.
In uporaba:
Ko bos želel analizirati podatke, boš enostavno povezal tabelo ekipe s prometnimi podatki, to je evidenco izvedenih tekem in njihovimi rezultati. če bos želel dobiti rezultate tujih ekip boš enostavno rekel naj bo vrednost v polju, ki vsebuje oznako dom/tuj v ekipi enak vrednosti, ki predstavlja tuje ekipe. (npr.: 1=domača,2=tuja)

Kot je že bilo omenjeno je design baze zelo pomemben. Če v začetku narobe zastaviš, se lahko zgodi, da boš moral od začetka. Ta moment se pojavi pri kasnejšem dopolnjevanju z novimi funkcijami, ko ugotoviš, da enostavne ne gre več naprej.

Še glede id povezav.
Iz lastne prakse vem, da ta način ni najboljši. Pomaga v primerih, ko potrebuješ več tujih ključev v eni tabeli. Glavni problem pa je v tem, da id predstavlja neko zaporedno številko, ki ti nič ne pove dokler je ne povežeš s tabelo, kjer so glavni podatki te id številke. Če je ta id številka enaka identifikaciji nosilca podatkov potem je to OK, drugače pa ne. Tak primer je šifra partnerja.
O tem je bilo nekaj napisano tudi v Monitorju v enem članku o testu programske opreme kakšno leto nazaj, kjer je takšen (id) način povezav bil zelo kritiziran.

Upam, da sem napisal kaj uporabnega.

To je sedaj že boljše. Sedaj pa postane problem poznavanja vsebine in ker jaz nisem pristaš nogometa, ti glede vsebine ne bom mogel več pomagati. Kot idejo še mogoče tole: Igralci prehajajo iz ene ekipe v drugo, (kje imaš pa podatke kluba?!). Mogoče bi bilo dobro tudi to spremljati. V tabeli igralec imaš samo trenutno stanje. Jaz bi naredil še tabelo, kjer bi beležil prehode, če so seveda pomembni.

Pri postavljanju sistema se moraš postaviti na stran uporabnika tega sistema in poskusiti uganiti, kaj bi na njegovem mestu želel od takega sistema ali pa to zvedeti od njega. Tu pride do izraza tvoja domišljija in kreativnost.

Mogoče še glede standardizacije. Izdelat si moraš sistem imenovanja objektov od tabel, polj v tabelah procedur itd in se tega potem držati. prav tako je potrebno standardizirati izgled mask in reportov. Poskusi najti svoj izraz. Po tem boš prepoznan !!

Želim ti uspešen napredek in lep pozdrav !