SQL databázy
Re: SQL databázy
Rado sa stalo
v tejto oblasti kedykoľvek
Re: SQL databázy
dnes som opravil tie inner joins (zabudol som dat do selectu polia z p2-pn) a moril som sa so syntaxou count, ale tie lahsie queries som urobil. teraz ale potrebujem count, kde je jeden stlpec vacsi ako druhy.
schema tabulky
kedze mam urcit kolko setov hrac vyhral, tak count bude takto?
najradsej by som to skusal pokus-omyl, ale to by slo len v labaku v skole a tu predsa len na noc zatvraju. do DB sa sa z domu nedostanem.
schema tabulky
Kód: Vybrať všetko
Score
'Side1Set1',`Side2Set1`, `Side1Set2`, `Side2Set2`, `Side1Set3`, `Side2Set3`, `Side1Set4`, `Side2Set4`, `Side1Set5`, `Side2Set5`Kód: Vybrať všetko
SELECT
COUNT(Score) AS WonSets
WHERE Side2Set1>Side2Set1 OR Side1Set1<Side2Set1 ...Re: SQL databázy
Count je agregačná funkcia - tj. agreguje RIADKY. Ty máš celú informáciu v jednom riadku(?!), čo je nábeh na veľmi zlý návrh v prípade, že modeluješ niečo ako tenis.
Ukáž celú schému tabulky, nemôže to byť takéto hnusné.
A toto je tzv. WTF podmienka
Ukáž celú schému tabulky, nemôže to byť takéto hnusné.
A toto je tzv. WTF podmienka
Kód: Vybrať všetko
where Side2Set1>Side2Set1Re: SQL databázy
Úplne hrozný model. Set mohol mať vlastnú tabuľku so stĺpcami číslo setu, player1body, player2body. Tak by to šlo jednoducho cez count.
Takto to musíš dostať namahavo z jedného riadka. Takže môžeš prerobiť model, alebo chceš riešenie na tento?
Takto to musíš dostať namahavo z jedného riadka. Takže môžeš prerobiť model, alebo chceš riešenie na tento?
Re: SQL databázy
Desim sa predstavy prepisania 125 setov do novej tabule. Ale pracovat sa s tym bude urcite lepsie
Re: SQL databázy
mozno bude rychlejsie spravit nejaky migracny skript.
nemuselo by to byt tak zlozite.
nemuselo by to byt tak zlozite.
-
audiotrack
VIP
- Príspevky: 25958
- Registrovaný: 09 sep 2005, 18:39
- Kontaktovať používateľa:
Re: SQL databázy
tých chýb je tam podstatne viac. Už len samotné názvy sú zle zvolené. CNo, VNo, MNo, SNo, PNo, Mno, .. wtf? Dúfam že tam máš minimálne komentáre, a ak to budeš prerábať, tak ich pomenuješ aby tomu rozumel aj niekto iný ako ty sám.
Fname, Lname, Sex a Age by mali mať všetci traja (hráč, staff aj návštevník). Neviem prečo ťa pri návštevníkoch nezaujíma Sex ale zaujíma ťa vek, naopak prečo je ti jedno že si môže hrať tenis v jednom zápase 15 ročný žiak s 30 ročným hráčom (a ty to spätne nezistíš). Ak tieto 4 atribúty vyčleníš do samostatnej tabuľky Person, a tie tri ju budú iba rozširovať o ďalšie atribúty, bolo by to lepšie ako takto duplikovať údaje (ak príde hráč na iný zápas ako hosť, eviduješ ho ako novú osobu aj keď je to ten istý. Ako chceš potom napríklad zistiť verných návštevníkov pre zlavy a pod?)
Tie vzťahy tam máš tiež hala-bala. Napríklad event-staff máš 1:*. Čiže podla tvojho zápisu jeden človek spravuje viacero eventov (neviem čo si predstaviť pod staff-member, ale napríklad taký nosič loptičiek naháňa loptičky po všetkých kurtoch naraz? Asi nie, že?). To je nejaká skúpa asociácia, že platia iba jedného človeka čo to všetko stíha
Neviem čo za program to máš, ale je hrozný. Kde končí tá šípka čo ide z "Player" ani srnky netušia. Ide aj do score aj do event. Ku ktorému platí ten vzťah 1:*? K obom? K jednému z nich? Čo ten druhý? Majú to byť dve samostatné asociácie, nie takto hrozne zoskupené do jednej šípky)
Player-event by mala byť spájacia tabuľka a nie pchať 4 hráčov do eventu, aj keď tam vo vela prípadoch budú dva ako null. No a o tenise teda vela neviem, ale ti stlpce winner sú tam tiež zbytočné. Je to hodnota ktorú vieš dopočítať, nemá v db čo robiť. Taktiež tie side* atribúty, ale to ti už BX písal že to treba celé prerobiť. Neviem prečo si chceš evidovať set z každej "strany". A celkovo mi príde asi lepšie evidovať gamy a sety z toho vieš dopočítať (pre stranu ktorá ťa zaujíma)
Viem že sa učíš, ale ty si tam snáď porušil všetko čo sa píše v každej knižke o návrhu databáz. Ak si začal s literatúrou, tak sa k nej vráť a prečítaj si to ešte raz. A ak si začal rovno tvoriť s tým, že si myslíš že vieš viac ako v knižkách a že na všetko prídeš vlastnou hlavou, tak vedz že nie. Návrh db nie je tak triviálny ako sa na prvý pohlad zdá. A hlavne, ak to nespravíš dobre, tak si narobíš veľmi veľa problémov do budúcnosti
Fname, Lname, Sex a Age by mali mať všetci traja (hráč, staff aj návštevník). Neviem prečo ťa pri návštevníkoch nezaujíma Sex ale zaujíma ťa vek, naopak prečo je ti jedno že si môže hrať tenis v jednom zápase 15 ročný žiak s 30 ročným hráčom (a ty to spätne nezistíš). Ak tieto 4 atribúty vyčleníš do samostatnej tabuľky Person, a tie tri ju budú iba rozširovať o ďalšie atribúty, bolo by to lepšie ako takto duplikovať údaje (ak príde hráč na iný zápas ako hosť, eviduješ ho ako novú osobu aj keď je to ten istý. Ako chceš potom napríklad zistiť verných návštevníkov pre zlavy a pod?)
Tie vzťahy tam máš tiež hala-bala. Napríklad event-staff máš 1:*. Čiže podla tvojho zápisu jeden človek spravuje viacero eventov (neviem čo si predstaviť pod staff-member, ale napríklad taký nosič loptičiek naháňa loptičky po všetkých kurtoch naraz? Asi nie, že?). To je nejaká skúpa asociácia, že platia iba jedného človeka čo to všetko stíha
Neviem čo za program to máš, ale je hrozný. Kde končí tá šípka čo ide z "Player" ani srnky netušia. Ide aj do score aj do event. Ku ktorému platí ten vzťah 1:*? K obom? K jednému z nich? Čo ten druhý? Majú to byť dve samostatné asociácie, nie takto hrozne zoskupené do jednej šípky)
Player-event by mala byť spájacia tabuľka a nie pchať 4 hráčov do eventu, aj keď tam vo vela prípadoch budú dva ako null. No a o tenise teda vela neviem, ale ti stlpce winner sú tam tiež zbytočné. Je to hodnota ktorú vieš dopočítať, nemá v db čo robiť. Taktiež tie side* atribúty, ale to ti už BX písal že to treba celé prerobiť. Neviem prečo si chceš evidovať set z každej "strany". A celkovo mi príde asi lepšie evidovať gamy a sety z toho vieš dopočítať (pre stranu ktorá ťa zaujíma)
Viem že sa učíš, ale ty si tam snáď porušil všetko čo sa píše v každej knižke o návrhu databáz. Ak si začal s literatúrou, tak sa k nej vráť a prečítaj si to ešte raz. A ak si začal rovno tvoriť s tým, že si myslíš že vieš viac ako v knižkách a že na všetko prídeš vlastnou hlavou, tak vedz že nie. Návrh db nie je tak triviálny ako sa na prvý pohlad zdá. A hlavne, ak to nespravíš dobre, tak si narobíš veľmi veľa problémov do budúcnosti
Re: SQL databázy
Jackb rýchly dotaz - máš to len ako úlohu do školy, ktorú chceš rýchlo vyriešiť, alebo sa to chceš naozaj naučiť? Nech vieme, akí zlí na teba máme byť 
A máš k tej úlohe zadané dáta/požiadavky, alebo si len tak vymýšľaš tenis a dáta si vymýšľaš sam?
A máš k tej úlohe zadané dáta/požiadavky, alebo si len tak vymýšľaš tenis a dáta si vymýšľaš sam?
Re: SQL databázy
BX, je to uloha. cas vratane textu mam este presne tyzden. ale kazdopadne mam z toho este skusku a chcem to vediet 
Toto odpovie aj audiovi:
Kedze zadanie je Wimbledon 2016 a vacsina z atributov je podla popisu zadania. Takze 15 rocny s 35 rocnym bude hrat len ked je seedovany na Wimb. Takze vek je irelevantny. Detto u rozhodcu, ci ball boy/girl. Ale u navstevnika mam informaciu, ze osoba pod 5 rokov ma vstup zadarmo. A mam pri navstevnikovi monitorovat ci je disable a ci teda potrebuje asistenciu.
Zo staffu aj tak pouzivam len rozhodcov, aj ked tam mam aj par ball boys/girls. Lebo jedna z poziadaviek je count zapasov, ktore rozhodca rozhodoval.
Jedine dilema je fakt to Score. Kedze som to chcel co najlahsie, tak som si tam tych vitazov pridal, aj ked sa mi tam vobec nepacia.
Diagram je z MS Visio. Stravil som tyzden hladanim dostupneho/free nastroja, ktory nepouziva Crow's feet. tie mame zakazane. takze som rezignoval a ostal pri tom co mi skola ponuka na pouzitie. Kazdopadne ho prekreslim pre odovzdanim, lebo takto znazornene vztahy nedavaju zmysel ani mne samemu. Je to vlastne stale nacrt.
Tie PNo, SNo,... urcite vysvetlim v texte, ale az na MNo v evente su mozno self explanatory. Event som povodne pomenoval Match, ale to sa nepacilo phpmyadmin pri queries, tak som to premenoval.
To ze mi single zapasoch vyhodi aj null viem odovodnit. Lebo takto to funguju celkom dobre pre stvorhru.
Tie strany su v skore preto, lebo ked dojde na stvorhru, je hrac nepouzitelny
Skutocne, vsetky problemy s queries, okrem score, nastali len mojou neznalostou syntax ako designom DB.
Toto odpovie aj audiovi:
Kedze zadanie je Wimbledon 2016 a vacsina z atributov je podla popisu zadania. Takze 15 rocny s 35 rocnym bude hrat len ked je seedovany na Wimb. Takze vek je irelevantny. Detto u rozhodcu, ci ball boy/girl. Ale u navstevnika mam informaciu, ze osoba pod 5 rokov ma vstup zadarmo. A mam pri navstevnikovi monitorovat ci je disable a ci teda potrebuje asistenciu.
Zo staffu aj tak pouzivam len rozhodcov, aj ked tam mam aj par ball boys/girls. Lebo jedna z poziadaviek je count zapasov, ktore rozhodca rozhodoval.
Jedine dilema je fakt to Score. Kedze som to chcel co najlahsie, tak som si tam tych vitazov pridal, aj ked sa mi tam vobec nepacia.
Diagram je z MS Visio. Stravil som tyzden hladanim dostupneho/free nastroja, ktory nepouziva Crow's feet. tie mame zakazane. takze som rezignoval a ostal pri tom co mi skola ponuka na pouzitie. Kazdopadne ho prekreslim pre odovzdanim, lebo takto znazornene vztahy nedavaju zmysel ani mne samemu. Je to vlastne stale nacrt.
Tie PNo, SNo,... urcite vysvetlim v texte, ale az na MNo v evente su mozno self explanatory. Event som povodne pomenoval Match, ale to sa nepacilo phpmyadmin pri queries, tak som to premenoval.
To ze mi single zapasoch vyhodi aj null viem odovodnit. Lebo takto to funguju celkom dobre pre stvorhru.
Tie strany su v skore preto, lebo ked dojde na stvorhru, je hrac nepouzitelny
Skutocne, vsetky problemy s queries, okrem score, nastali len mojou neznalostou syntax ako designom DB.
-
audiotrack
VIP
- Príspevky: 25958
- Registrovaný: 09 sep 2005, 18:39
- Kontaktovať používateľa:
Re: SQL databázy
self explanatory to určite nie sú, lebo PNo nič nevysvetluje. Musíš k tomu poznať názov ďalších tabuliek a prepojenie s nimi. A tým pádom sa to už nevysvetluje samo, keď ti k tomu treba ďalšie informácie. Self explanator by bol PlayerID alebo PlayerNumber. Takéto identifikátory dávajú zmysel aj po zmene názvu inej tabuľky, čo sa v tvojom prípade stalo. Ak je to PNo a pribudne tabuľka Person k tej Player, tak už sa v tom stratíš totálnejackb napísal: Tie PNo, SNo,... urcite vysvetlim v texte, ale az na MNo v evente su mozno self explanatory.
Pri štvorhre máš stále len dvoch "hráčov", akurát sú zložený z dvoch osôb. Skóre sa tej dvojici ráta dokopy, a aj víťazi sú obaja naraz. Nevystupujú tam 4 hráči, ale dva tímy. Takisto v dvojhre si to vieš definovať že nehrajú dvaja hráči, ale dva tímy (po jednom členovi). Toto všetko sa dá krásne vyriešiť, len to chce trošku abstrakcie v myslení
Ak sú staff rozhodcovia, treba to pomenovať ako rozhodcovia. Alebo tým staff dať atribút (ešte lepšie prepojoviaciu tabuľku s novou tabuľkou rolí) aby sa vedelo čo za človeka to je. Takto máš zápasy iba s rozhodcami (čo je okrem iného blbosť) a bez toho aby si to takto vysvetlil, ten vzťah nedáva zmysel lebo okolo zápasu je istotne viac ľudí ako jeden
nástrojov je mrte, z tých free napríklad dia alebo aj plno programátorských editorov má pluginy na diagramy. Napríklad netbeans. Prípadne si mohol použiť aj trial, ak je to len pre zadanie do školy. Enterprise architect je veľmi dobrý a má 30 dňový trial čo ti bohate stačí. Rovnako tak plno iných. Alebo aj spomínané visio, len ty si akurát vybral nejaký zlý typ diagramu, pretože podla googlu vyzerajú celkom fajn (vlastne tak, ako je štandard): https://goo.gl/2Dgp0H
Re: SQL databázy
Tabulku Person ale skutocne nechcem. No problem zmenit tie XNo za nieco co dava zmysel a pomenit to v existujucich queries nebude.
Ako som napisal, v Staff su aj nosici lopticiek, ale do ziadneho zapasu som ich nepridal, lebo sa nich nikto nepyta. Len zadanie hovori o vsetkych ludoch, ktori okolo toho su. // - mam tam position, co urcuje, co dany clen staffu robi
Ano, preto mam pri Score dvoch winnerov - pre pripad stvorhry. A rozumiem aj tym teamom, ale bolo by pracne nachovat tabulky a tiez urobit na ne JOINs z nich v queries
// ano, vo Visio som pouzil prvy LAYOUT, ktory sa najviac podobal tomu co mam urobit.
//autoeditácia príspevku (06 Nov 2015, 14:14)
aj ked sa da uloha spravit s tym nepodarkom, ktory som ukazal a doplnenim o tabulku set + premenovanim xNo na zmyslupne veci, tak sa ku tomuto vratim a skusim vsetko aj tie teamy a vsetko co pise audio a napise niekto dalsi
//autoeditácia príspevku (06 Nov 2015, 21:25)
Tabula prerobena na Sety, podla BXa. Score teraz odkazuje na unikatne sety s ich vysledkami.
Ale stracam predstavu ako sparovat hraca/team s tym kto dany set vyhral
Ako som napisal, v Staff su aj nosici lopticiek, ale do ziadneho zapasu som ich nepridal, lebo sa nich nikto nepyta. Len zadanie hovori o vsetkych ludoch, ktori okolo toho su. // - mam tam position, co urcuje, co dany clen staffu robi
Ano, preto mam pri Score dvoch winnerov - pre pripad stvorhry. A rozumiem aj tym teamom, ale bolo by pracne nachovat tabulky a tiez urobit na ne JOINs z nich v queries
// ano, vo Visio som pouzil prvy LAYOUT, ktory sa najviac podobal tomu co mam urobit.
//autoeditácia príspevku (06 Nov 2015, 14:14)
aj ked sa da uloha spravit s tym nepodarkom, ktory som ukazal a doplnenim o tabulku set + premenovanim xNo na zmyslupne veci, tak sa ku tomuto vratim a skusim vsetko aj tie teamy a vsetko co pise audio a napise niekto dalsi
//autoeditácia príspevku (06 Nov 2015, 21:25)
Tabula prerobena na Sety, podla BXa. Score teraz odkazuje na unikatne sety s ich vysledkami.
Ale stracam predstavu ako sparovat hraca/team s tym kto dany set vyhral
Re: SQL databázy
Vždy prilož obrázok modelu, nech je jasné, o čom sa bavíme.
Re: SQL databázy
tak som prekreslil v dia.
velka vdaka Audio - praca bola podstatne prijemnejsia ako vo Visio
velka vdaka Audio - praca bola podstatne prijemnejsia ako vo Visio
Re: SQL databázy
Prečo sa furt snažíš napchať celu hru do jedného riadka? Čo set, to záznam. Score ani ten part ti netreba. Na event pripoj set a máš.
Re: SQL databázy
Len stale neviem urcit kto je ktora strana.
A z momentalnej tabule viem lahko urcit kolko zapasov hrac vyhral a ake bolo skore v zapasoch. Preto mi pride riesenie, kde su vysledky setov v jedinom riadku lepsie, ako dat sety rovno do zapasu
A z momentalnej tabule viem lahko urcit kolko zapasov hrac vyhral a ake bolo skore v zapasoch. Preto mi pride riesenie, kde su vysledky setov v jedinom riadku lepsie, ako dat sety rovno do zapasu
Re: SQL databázy
Ťažko sa opravuje tento model, lebo je celý zlý 
Ja som si až teraz všimol, že ty máš v Evente ScoreNumber. To znamená, že potrebuješ mať záznam Score skôr, než vytvoríš Event - a to je trochu hovadina čo? (to isté aj staff)
Celé to vidíš zle. Event je udalosť a má obsahovať len potrebné info. Takže ID, hráčov (dajme tomu, v tomto prípade), kurt a čas. Priebeh hry je sekvencia setov. Každý set je identifikovaný event id a číslom setu.
Jeden set teda bude event id, číslo setu, side1body, side2body a to je všetko. Štvorhra je komplikácia, ak nechceš týmy (ako písal audio), môžeš to trochu obabrať - u dvojhry bude hrať player1 a player3, u štvorhry doplnis player2 a 4 (toto je myšlienka, logika modelu, do modelu to nijak premietnuť nemusíš)
Tabulky score a part tak môžeš zmazať, staci ti set.
Ja som si až teraz všimol, že ty máš v Evente ScoreNumber. To znamená, že potrebuješ mať záznam Score skôr, než vytvoríš Event - a to je trochu hovadina čo? (to isté aj staff)
Celé to vidíš zle. Event je udalosť a má obsahovať len potrebné info. Takže ID, hráčov (dajme tomu, v tomto prípade), kurt a čas. Priebeh hry je sekvencia setov. Každý set je identifikovaný event id a číslom setu.
Jeden set teda bude event id, číslo setu, side1body, side2body a to je všetko. Štvorhra je komplikácia, ak nechceš týmy (ako písal audio), môžeš to trochu obabrať - u dvojhry bude hrať player1 a player3, u štvorhry doplnis player2 a 4 (toto je myšlienka, logika modelu, do modelu to nijak premietnuť nemusíš)
Tabulky score a part tak môžeš zmazať, staci ti set.
Re: SQL databázy
ale Part je tabulka kde su sety. Nazov Set je keyword, to iste ako Match. Preto sa Zapas vola Event a Set zase Part.
Ako je z diagramu zrejme, tak v Part je ID Setu a skore kazdej strany v unikatnom sete. Party su potom podla unikatneho SetNo pridelene ku skore zapasom, v ktorych sa stali. Winner v Skore nemusi urcit vitaza vsetkych Partov.
Tabulky, okrem Set/Part som robil podla toho co mam z tej databazy dostat a vedel by som to relativne co najrychlejsie. A na 9 z 10 otazok to aj ide. Az na tu siestu.
//autoeditácia príspevku (07 Nov 2015, 19:21)
Anyway, ak by som zrusil tabulu Score a namiesto toho by som SetNos napchal do Eventu tak aj tak sa tabule part neprijoinujem na udaje o hracovi a aj keby som vedel ako vypocitat vitaza aj tak ho neurcim
//autoeditácia príspevku (07 Nov 2015, 20:09)
Dobre, pridane ID Eventu do Tabule Part. Takze takto som odpovedal na otazku 2
A na otazku 3 nasledne
a odpoved na 6 je tiez far away...
//autoeditácia príspevku (07 Nov 2015, 20:50)
v 4 skusam teda vyhrane zpasy urcit ako pripad kedy je sucet setov pre jednu stranu vyssi ako sucet druhej
spravne to nie je hlavne preto, lebo to nezobrazi zapasy vyhrane playermi 2 a 4. takze na uplne splenie tam este nema zmysel dat count. a to netusim co by scitovalo, lebo bez toho group su tam stovky riadkov...
//autoeditácia príspevku (08 Nov 2015, 10:09)
nemozem jednoducho ku setu urcit kto ho vyhral, aby som podla toho pocital zapasy/sety?
//autoeditácia príspevku (08 Nov 2015, 17:15)
dnes som skusil pridat vitazov Partov a pocitat ich cez SUM
ale aj tam robim nieco zle
Ako je z diagramu zrejme, tak v Part je ID Setu a skore kazdej strany v unikatnom sete. Party su potom podla unikatneho SetNo pridelene ku skore zapasom, v ktorych sa stali. Winner v Skore nemusi urcit vitaza vsetkych Partov.
Tabulky, okrem Set/Part som robil podla toho co mam z tej databazy dostat a vedel by som to relativne co najrychlejsie. A na 9 z 10 otazok to aj ide. Az na tu siestu.
//autoeditácia príspevku (07 Nov 2015, 19:21)
Anyway, ak by som zrusil tabulu Score a namiesto toho by som SetNos napchal do Eventu tak aj tak sa tabule part neprijoinujem na udaje o hracovi a aj keby som vedel ako vypocitat vitaza aj tak ho neurcim
//autoeditácia príspevku (07 Nov 2015, 20:09)
Dobre, pridane ID Eventu do Tabule Part. Takze takto som odpovedal na otazku 2
Kód: Vybrať všetko
SELECT
Event.MNo,
Part.Side1 AS Side1Set1,
Part.Side2 AS Side2Set1,
pa2.Side1 AS Side1Set2,
pa2.Side2 AS Side2Set2,
pa3.Side1 AS Side1Set3,
pa3.Side2 AS Side2Set3,
pa4.Side1 AS Side1Set4,
pa4.Side2 AS Side2Set4,
pa5.Side1 AS Side1Set5,
pa5.Side2 AS Side2Set5,
Player.FName,
Player.FName,
Player.LName,
p2.FName,
p2.LName,
p3.FName,
p3.LName,
p4.FName,
p4.LName
FROM
Event
LEFT JOIN Part
ON Event.MNo=Part.MNo
LEFT JOIN Part pa2
ON Event.MNo=pa2.MNo
LEFT JOIN Part pa3
ON Event.MNo=pa3.MNo
LEFT JOIN Part pa4
ON Event.MNo=pa4.MNo
LEFT JOIN Part pa5
ON Event.MNo=pa5.MNo
LEFT JOIN Player
ON Event.Player1=Player.PNo
LEFT JOIN Player p2
ON Event.Player2=p2.PNo
LEFt JOIN Player p3
ON Event.Player3=p3.PNo
LEFT JOIN Player p4
ON Event.Player4=p4.PNono aj tak netusim ako napisat count, aby to do otazky 4 vyratalo vitaza/ov. aj ked moj system je "parni" a "neparni" - teda v stvrohre su spolu ti, ktori su 1 a 3.SELECT
Event.MNo,
Part.Side1 AS Side1Set1,
Part.Side2 AS Side2Set1,
pa2.Side1 AS Side1Set2,
pa2.Side2 AS Side2Set2,
pa3.Side1 AS Side1Set3,
pa3.Side2 AS Side2Set3,
pa4.Side1 AS Side1Set4,
pa4.Side2 AS Side2Set4,
pa5.Side1 AS Side1Set5,
pa5.Side2 AS Side2Set5,
Player.FName,
Player.LName,
p2.FName,
p2.LName,
p3.FName,
p3.LName,
p4.FName,
p4.LName
FROM
Event
LEFT JOIN Part
ON Event.MNo=Part.MNo
LEFT JOIN Part pa2
ON Event.MNo=pa2.MNo
LEFT JOIN Part pa3
ON Event.MNo=pa3.MNo
LEFT JOIN Part pa4
ON Event.MNo=pa4.MNo
LEFT JOIN Part pa5
ON Event.MNo=pa5.MNo
INNER JOIN Player
ON Event.Player1=Player.PNo
LEFT JOIN Player p2
ON Event.Player2=p2.PNo
LEFt JOIN Player p3
ON Event.Player3=p3.PNo
LEFT JOIN Player p4
ON Event.Player4=p4.PNo
WHERE Event.Player1='P033' OR Event.Player2='P033' OR Event.Player3='P033' OR Event.Player4='P033'
GROUP BY Event.MNo
a odpoved na 6 je tiez far away...
//autoeditácia príspevku (07 Nov 2015, 20:50)
v 4 skusam teda vyhrane zpasy urcit ako pripad kedy je sucet setov pre jednu stranu vyssi ako sucet druhej
Kód: Vybrať všetko
SELECT
Event.MNo,
Player.FName,
Player.LName
FROM
Event
LEFT JOIN Part
ON Event.MNo=Part.MNo
LEFT JOIN Part pa2
ON Event.MNo=pa2.MNo
LEFT JOIN Part pa3
ON Event.MNo=pa3.MNo
LEFT JOIN Part pa4
ON Event.MNo=pa4.MNo
LEFT JOIN Part pa5
ON Event.MNo=pa5.MNo
LEFT JOIN Player
ON Event.Player1=Player.PNo
WHERE Part.Side1+pa2.Side1+pa3.Side1+pa4.Side1+pa5.Side1>Part.Side2+pa2.Side2+pa3.Side2+pa4.Side2+pa5.Side2 AND Event.Player1=Player.PNo OR Event.Player3=Player.PNo
OR Part.Side1+pa2.Side1+pa3.Side1+pa4.Side1+pa5.Side1<Part.Side2+pa2.Side2+pa3.Side2+pa4.Side2+pa5.Side2 AND Event.Player2=Player.PNo OR Event.Player4=Player.PNo
GROUP BY Event.Mno//autoeditácia príspevku (08 Nov 2015, 10:09)
nemozem jednoducho ku setu urcit kto ho vyhral, aby som podla toho pocital zapasy/sety?
//autoeditácia príspevku (08 Nov 2015, 17:15)
dnes som skusil pridat vitazov Partov a pocitat ich cez SUM
ale aj tam robim nieco zle
Kód: Vybrať všetko
SELECT
Part.Mno
SUM (CASE WHEN Part.Winner='1' THEN 1 ELSE 0 END) AS 1winner,
SUM (CASE WHEN Part.Winner='2' THEN 1 ELSE 0 END) AS 2winner
FROM
Part
GROUP By
Part.Mno