» »

Nekdaj glede MySQL podatkovne baze

Nekdaj glede MySQL podatkovne baze

Crimson_Shadow ::

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.

BigWhale ::

Ja lahko, vendar je vprasanje, ce se ti do dejansko splaca nardit, ker to ven iz SQLa potegnit, sicer ni komplicirano, ni pa tudi blazno enostavno, je pa time consuming. Skoda CPU casa, ce imas dovolj diska, da shranis se da INT-a v bazo, pa imas dovolj prostora za gole do konca stoletja ;)

Eh, vsak krog je svoja vrstica v tabeli. Recimo, da je model takle:

team, incoming, outgoing, result

potem samo zapisujes za vsak krog in za vsako mostvo

1,1,1,0
2,1,0,1
3,1,1,0
4,0,1,2

Stiri mostva, dva sta igrala neodloceno, v drugi tekmi je pa mostvo st. 2 zmagalo z enim golom.

naslednji teden pa isto... 1,2,3,4 ...

Prostor verjetno ne bo problem, pri 30 ekipah je to tedensko 30 vrstic v tabeli, torej letno okrog 1500 vrstic? Pa dobis avtomatsko celoten history, izracun trenutnega stevila golov, zmag, porazov in izenacenih tekem je trivialen,... Pa zraven das se datum, pa stevilo prekrskov, kartonov, etc, etc, pa se ti vse kumulira po tednih..

Hja, tako bi jaz to naredil, ker sem nagnjen k precej kmeckemu pristopu resevanja problemov ;>

Crimson_Shadow ::

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.

BigWhale ::

To je ze cel DB design... ;) Tukaj moras naredit stvari pravilno, ker ce fsckjas tukaj, se bo sranje vleklo cez celo aplikacijo... ;)

Najprej ugotovi iz cesa bos izhajal, verjetno je to mostvo. Potem naredis en sifrant igralcev, kamor vneses vse igralce. Potem jih pa samo premikas po mostvih, gor in dol, ali jih pa das na 'cakanje' ce recimo nikjer ne igra eno sezono. Omislis si se poseben status za tiste, ki so polomljeni in tako naprej.

Sifrant tekem, bo tudi potreben. Ime mostva in igralca je nepomemben podatek, saj se lahko spreminja. ;)

Eno tako zlato pravilo, ki se ga jaz drzim, vsaka tabela ima stolpec ID, ki je zaporedna stevilka vnosa v tabelo... To ti povezovanje precej olajsa... ;)

BTW, A nam lahko zaupas na katerem faxu te tega niso naucili ;)

Crimson_Shadow ::

:D Se kje iz mojih dveh sporočil to vidi :D. 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.

BigWhale ::

Ne bom trdil, da sem cist preprican, ce se razumeva. ;>

Ok, vseeno, Zakaj pa posebna tabela za sezone? Saj sezona je samo integer? 2002, 2003, 2004, ...

Anyway, zato pa imas SQL in deset vrstic dolge selecte, da lahko izkoristis moznost veliko relacij... :)

Crimson_Shadow ::

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?

Ziga Dolhar ::

Izkoristi relacije.

sezonaID | ime | trajanje | Bla 1 | Bla 2
1 2002/2003 | januar 2002 - februar 2003 | Bla1 | Bla 2

...


Potem pa vsaki tekmi določiš sezono.

Podatki tamle gor so seveda provizorični, tem športom ne sledim :-)

Saj veš: ponavljajoče podatke načeloma izločiš v ločene tabele, na katere se potem sklicuješ.
https://dolhar.si/

Zgodovina sprememb…

darh ::

> 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;



>:D
Excuses are useless! Results are priceless!

Zgodovina sprememb…

  • spremenil: darh ()

Crimson_Shadow ::

Ker mam dokaj malo prakse s tem, me zanima, kako je, če bi bil primarni ključ tak, da bi ga moral sam vpisati pri vnašanju podatkov (recimo, 200103 namesto običajnega 1, 2, 3, ... )?

darh ::

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..
Excuses are useless! Results are priceless!

Crimson_Shadow ::

Sedaj sem probal postaviti to v Accessu (za probat in testirat). Predvsem me zanima kaj pomeni, da ti Access ustvari novo tabelo, recimo EKIPA_1 pri vzpostavljanju povezav? Ne mi reč, da je to nova tabela, ker tega nočem?

Poglejte sem!

Hočem pa povezati ID_ekipe iz EKIPA v obe, tako ID_domačl kot ID_tuji v tabeli TEKMA.

zdravc ::

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.
kdor zna pa žih

Crimson_Shadow ::

Sem malce drugače zastavil in tu je popravljena baza.

Sem!

Je boljše? Ali bi se dalo še izboljšati relacije? Ne bi imel nič proti, če mi kdo pokaže svojo rešitev. Pa ni treba reševati mojega probelma, zanima me samo ali je kdo od vas kaj podobnega že delal v preteklosti in bi imel še shranjeno na disku?

Ups! Za razjasnitev. V tabeli TEKMA je SF_ekipa zato, da se ve katera ekipa igra doma in ne katera ekipa igra.

zdravc ::

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 !
kdor zna pa žih


Vredno ogleda ...

TemaSporočilaOglediZadnje sporočilo
TemaSporočilaOglediZadnje sporočilo
»

Evropske lige v športnih tekmovanjih

Oddelek: Šport
9831 (714) Drevesce
»

SQL pomoč

Oddelek: Programiranje
131915 (1329) miko22
»

Iščem mini-ranking sistem

Oddelek: Izdelava spletišč
5785 (693) dinozaver7
»

Salzburg do izenačenja (strani: 1 2 )

Oddelek: Loža
615325 (3676) Ejsi_Disi
»

union olimpija:žalgiris prenos tekme (strani: 1 2 3 )

Oddelek: Loža
1209655 (7756) primozzzz

Več podobnih tem