Autor Zpráva
Kcko
Profil
Ahoj, mensi problemek ...

opet z fotbaloveho sveta ...

Mam vypis tymu, sesortovany podle urcitych parametru ( body, vstrelene goly, obdrzene goly atd.)
Kdyz maji 2 tymy stejny pocet vsech parametru, tak logicky jsou na stejne pozici, toto zatim resim aplikacne.

Neco ve smyslu


 $i=0;
  $minulypocet=0;
  while($r=mfa($sql)) {
  $i++;
 
  if ($minulypocet==$r[TOTAL])
    $pozice=  " ";
  else
    $pozice= "$i.";

  $minulypocet = $r[TOTAL];
 }




Jenze nyni bych si to rad ulozil ke kazdemu tymu do DB onu pozici.

1/ muzu to aplikacne zapsat viz ukazka, nicmene tabulka muze mit treba 500 tymu tj => 500x update na DB se mi moc nelibi
2/ muzu zkusit proceduru ktera bude rychlejsi, ale porad to neni to co bych si predstavoval
3/ precislovat to pomoci databazovych promennych "@", akorat to nemuzu vymyslet :-)


Takze bych prosil o radu nebo o nakopnuti smerem k bodu cislo 3/
Kcko
Profil
No jo tak si odpovim sam , napsal sem si proceduru, ale kdyby znal nekdo snazsi zpusob ...


CREATE PROCEDURE SP_poradi()
BEGIN

DECLARE s_poradi INT(5);
DECLARE s_body INT(5);
DECLARE temp_body INT(5) DEFAULT 0;
DECLARE s_tym VARCHAR(50);
DECLARE my_rank INT(5) DEFAULT 0;
DECLARE done TINYINT(1) DEFAULT 0;

DECLARE i INT;

DECLARE rank CURSOR FOR
SELECT tym, body, poradi FROM poradi
ORDER BY body DESC;

DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = 1;

SET i = 0;
OPEN rank;
rank_loop:  LOOP

FETCH rank INTO s_tym, s_body, s_poradi;
IF done THEN LEAVE rank_loop; END IF;



IF (temp_body <> s_body)
  THEN UPDATE poradi SET poradi = i + 1 WHERE tym = s_tym;
ELSE
  UPDATE poradi SET poradi = i + 0 WHERE tym = s_tym;
END IF;

SET i=i+1;
SET temp_body = s_body;  


END LOOP rank_loop;
CLOSE rank;

END;

Kcko
Profil
PS. Otazkou je , jak moc to bude rychle? Nemate s tim nekdo zkusenosti, kolega mi prave rekl abych se na SP vykaslal, ze jeho SP ktera preukladala jednoducha data v podobe asi 40tis. radku do jine tabulky trvala pul hodiny a ze sou SP jeste nevychatane stale.

Diky
TomášK
Profil
Podobným problém s očíslováním jsem řešil a přišel jsem na následující řešení (seřazené podle toho, jak je považuju za vhodné):

1, přejít od MySQL k databázi, která podporuje analytické funkce,
třeba PostresSQL 8.4. Pro srovnání dotaz ekvivaletní tvé proceduře by vypadal asi takto:
SELECT rank() OVER w, tym.id FROM tabulka WINDOW w AS (ORDER BY body DESC);

2, Stored procedura.
3,pomocí @, většinou to funguje, už jsem se na tom i spálil - při složitějším dotazu mi to fungovat přestalo, i jsem tam
našel jeden tuším GROUP BY, který rozhodoval o tom, jestli se to očísluje správně nebo ne. Proto
tohle řešení nemám moc rád a radši si dám práci s tou procedurou. Idea vypadá takto:
SET @poradi := 1;
SET @body := -1;
SELECT 
    @poradi := @poradi + (@body = body) AS poradi,
    @body := body
    tym.id, ...
FROM 
    tabulka
ORDER BY body DESC


4, korelovaný poddotaz - narozdíl od SP má kvadratickou složitost oproti lineární, bude to pomalé. Hodně pomalé.
SELECT 
        (SELECT COUNT(*) FROM tabulka AS t WHERE t.body < tabulka.body) AS poradi,
        tym.id
    FROM tabulka



Co se týče výkonnosti SP - 500 záznamů je z hlediska databáze nezajímavé číslo - tím můžeš vyvádět
ledaccos (v rámci SP, 500 dotazů přes php by mohlo být o něco horší) a stejně to bude v sekundách.
Mám podobnou databázi pro deskovou hru. Stovky hráčů, stovky turnajů, desítky tisíc partiií. Z toho
počítám pořadí - jsou tam i výpočetně náročnější kritéria jako počet vítězství soupeře, z těch
pořadí dál počítam kvalifikaci, která závisí na umístění na turnaji (obojí čísluju). Předpočítání pořadí a
kvalifikace pro každý turnaj vytvoří celkem přes 100 000 záznamů a trvá cca půl minuty až minutu.
Výpočet je pomocí SP.
Kcko_zzz
Profil *
TomášK

Diky Tome za vycerpavajici odpoved.

1/ Nejak jsem teto DB neprisel na chut, mam rad MYSQL a PMA a nechci se momentalne ucit nic jineho, kdyz MYSQL neovladam jeste tak jak bych si predstavoval

2/ Ano ano, napsal jsem si

3/ Zitra si to jeste vyzkousim dle tve idey, ja prave toto ocislovani pomoci uz. promennych pouzivam, nicmene se to hodi opravdu na jednodussi pripady, a tenhle to zrovna nebyl

4/ Koukam, tohle me ani nenapadlo, ale rychle to asi moc nebude, ale zkusim si to taky :-)

Nakonec se ta SP jevi jako nejvhodnejsi ale pro klid na dusi variantu 2 a 4 zitra urcite vyzkousim

Kolega mel tu SP asi spatne napsanou, kdyz se mu generovala tak jak se mu generovala.

PS. mohl bych se na tebe s variantou 2 jeste obratit kdyz se mi nepodari tak jak si predstavuji?

Dobrou noc a diky
TomášK
Profil
Tohle je téma, které se tu v nějaké obměně čas od času objevuje, takže moje odpověď se s přibývajícími informacemi snad postupně zdokonaluje :)
Předpokládám, že mluvíš o 2 a myslíš 3. Ten dotaz nemusí být dobře, psal jsem ho z hlavy, ale rád ho upravím, pokud nebude fungovat. Už teď vidím jednu nedokonalost - pořadí bude vracet ve tvaru
1,1,2,3 místo zde zřejmě vhodnější 1,1,3,4.
K té 4 - zkoušel jsem to na tabulce o 100 000 záznamech a očíslovat prvních 10 trvalo cca 3s, prvních 100 trvalo 15 vteřin. Očíslování celé tabulky by bylo hotové předpokládám někdy nad ránem...
Kcko
Profil
CREATE PROCEDURE SP_Fill()
BEGIN

DECLARE i INT DEFAULT 0;



my_loop: LOOP
SET i = i + 1;
IF (i > 1000)
THEN LEAVE my_loop;
END IF;

INSERT INTO poradi VALUES(CONCAT('tym - ', i), i, 0);

END LOOP my_loop;
END;


Takze moje pokusy

tabulka o 1000 zaznamech.


varianta 4/



SELECT 
   (SELECT COUNT(*) + 1 FROM poradi as t1 WHERE t1.body > t2.body) AS rank, t2.tym, t2.body
    FROM poradi as t2



cas 0,02s ( nutno brat v potaz ze je to jen jedna podminka ve skutecnosti jich bude vic, takze i cas muze narust, ale nic drastickeho to asi nebude )


varianta 2/ ( SP )


Ocislovani 1000 radku trva cca 1,1 - 1,4s - coz neni extra, ale v aplikaci to poznat stejne nepujde, bude se to provadet jen pri ulozeni zapasu a uzivatel to ani nepostrehne


varianta 3/ ( pomoci uz. promennych "@")


To jsem nejak nerozchodil tu tvoji ideu :) bud mi to haze stejne poradi (porad 1 ) nebo NULL

varianta 1/ ocislovat to klasicky prasacky v cyklu pomoci mysql_query ( a taky bych rekl ze to nebude nic hrozneho = pomaleho )

Celkove vzato
- elegantni je SP, ale neni extra rychla
- dotaz z varianty 4 neni pomaly, ale ja potrebuji mit pozice ulozene natvrdo ( nicmene nekdy se to na neco hodit bude, proto si to ukladam do sveho MYSQL Hot-tips archivu :))
- variantu 3 jsem tedy nerozchodil, a asi na to kasleme , protoze je to uz na ukor citelnosti a pochopitelnosti (alespon pro mne )
- a varianta 1 - to je reznicina no ... ale nemyslim si ze by to bylo tak pomale, jeste si to musim vyzkouset.
TomášK
Profil
Mohl by to tu někdo prosím pročistit? Došlo k chybě, viz http://diskuse.jakpsatweb.cz/?action=vthread&forum=18&topic=97631 a Kcko zkoušel odesílat příspěvek víckrát.
Moderátor Chamurappi: Staniž se.

Zdály se mi ty výsledky podezřelé, a páč mě to zajímalo, zkusil jsem to. Testoval jsem 5000 řádků, aby ty rozdíly byly větší:

1/ ocislovat to klasicky prasacky v cyklu pomoci mysql_query
podle mě to bude stejně náročné, jako stored procedura + náklady na režii na komunikaci

2a, Stored procedura - 2min, 42sec
Tvá stored procedura mi ne neočíslovala správně, když mělo víc týmů stejně bodů, ale nechce se mi tam hledat chyba. Myslím, že tam je něco z hlediska náročnosti na výpočet nedůležité, ale na první pohled to nevidím. Mohlo to vzniknout i někde při přenosu...

2b, Stored procedura s indexem na sloupci tym - 1.64sec
Ten index stojí za to :) Jinak se tam při každém UPDATU prohledává celá tabulka.

3/ ( pomoci uz. promennych "@") - 0.04sec
SET @minule := 0;
SET @poradi := 0;
SET @radek := 1;
SELECT 
    tym,
    body,
    @poradi := IF(@minule = body, @poradi, @radek) AS poradi,
    @radek := @radek + 1 AS radek,
    @minule := body AS tmp
FROM 
    poradi
ORDER BY
 body DESC;


4a, poddotaz - 3 min 23sec
4a, poddotaz s indexem nad body - 1 min 27sec

Shrnutí:
- bezkonkurenčně nejrychlejší jsou uživatelské proměnné - jen hrozí, že se třeba změní verze MySQL a začne se dotaz chovat jinak. Asi ne, ale zaručené to nemám...
- stored procedura je elegantní a rychlá, jen potřebuje index
- poddotaz je pro trochu větší množinu už nepoužitelný. Index mu pomůže, ale pořád je nepoužitelný

- uložení natvrdo by určitě taky šlo vymyslet přes nějaký update. Přinejhorším procedura, která vytvoří dočasnou tabulku, nahraje do ní výsledky selectu a pak podle té tabulky zaktualizuje původní. Ale zdá se mi, že by to mohlo jít i celé jedním dotazem.
Kcko
Profil
Omlouvam se za opakovane prispevky, trefil sem se zrovna do doby kdy se forum zblaznilo a ja myslel ze pouze muj FF.


Jinak sem si tedy udelal taky zatezovy test ( opet na onech 1000 radcich )

1/ Je to bohuzel rychlejsi nez SP , cas je vzdy mezi 0,2 / 0,3s ( spise k nizsi hodnote )

2/ Tak samozrejme index bych nasadil ale SP je pomalejsi cas pri prvnim spusteni 0,8s, pri druhem 0,5s a pri dalsich rychle za sebou volanych prikazu se pohybuje kolem 0,2s stejne jako v prvni variante


3/ Hezky zpusob, musim si ho precist tak 5x jeste abych ho pochopil, jak by do nej sel zakomponovat rovnou update aby dosadil ony vypocitane pozice

4/ me vychazi pod 0,05s - zvlastni

PS. Jinak v te moji SP byla skutecne chyba, diky za upozorneni, opraveno =>


CREATE  PROCEDURE `SP_poradi`()
BEGIN

DECLARE s_poradi INT(5);
DECLARE s_body INT(5);
DECLARE temp_body INT(5) DEFAULT 0;
DECLARE s_tym VARCHAR(50);
DECLARE my_rank INT(5) DEFAULT 0;
DECLARE done TINYINT(1) DEFAULT 0;

DECLARE position TINYINT DEFAULT 0;

DECLARE i INT;

DECLARE rank CURSOR FOR
SELECT tym, body, poradi FROM poradi
ORDER BY body DESC;

DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = 1;

SET i = 0;
OPEN rank;
rank_loop:  LOOP

FETCH rank INTO s_tym, s_body, s_poradi;
IF done THEN LEAVE rank_loop; END IF;

SET i=i+1;

IF (temp_body <> s_body)
  THEN SET position = i;
ELSE
  SET position = position;
END IF;


UPDATE poradi SET poradi = position WHERE tym = s_tym;

SET temp_body = s_body;  


END LOOP rank_loop;
CLOSE rank;

END


Jinak pises ze nevis co by to tam mohlo byt z hlediska vypoctu slozite, no ono tam nic sloziteho neni ale proste musi zmenit 1000 radku a prochazi je po jednom, tak to proste neni hned :-) ( nejspis , o SP toho moc nevim )
Kcko
Profil
Tak jeste mensi info

Procedura je rychlejsi nez prasecina mysql_query v cyklu pri vetsim poctu radku, zkousim to ted na 10tis. zaznamech a rozdil je tam cca 20%

7,5s x 10/11s ( update nebo insert 10tis. zaznamu )

Pricemz

tvuj korelovany dotaz si s tim hrave poradi za 0,1 - 0,2s :)
(samozrejme, ze on jen taha data napric tomu ze SP ci proceduralni skript INSERTUJE / UPDATUJE hafo zaznamu) , ale stejne se mi to lisi oproti tobe ve vypoctech a to o hodne ..

PS. ICQ?


SELECT
(SELECT COUNT(*) + 1 FROM poradi as t1 WHERE t1.body > t2.body) AS rank, t2.tym, t2.body
FROM poradi as t2
Kcko
Profil
Mimo tento dotaz ale taky k SP
----------------------------------------

Potrebuji zjistit 4 posledni zapasy konkretnich hracu


cili sem si zkusil


CREATE PROCEDURE `RESULT` ()
BEGIN

DECLARE done TINYINT(1) DEFAULT 0;
DECLARE _id INT;
DECLARE _prezdivka VARCHAR(100);

DECLARE mycursor CURSOR FOR
SELECT id, prezdivka FROM hraci WHERE id IN (1, 11);

DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = 1;

OPEN mycursor;
myloop:  LOOP
FETCH mycursor INTO _id,  _prezdivka;
IF done THEN LEAVE myloop; END IF;

SELECT * FROM vysledky WHERE d_hrac = _id OR h_hrac = _id ORDER BY id_zapasu DESC LIMIT 4;

END LOOP myloop;
CLOSE mycursor;


END




v PMA to nefunguje neumi zobrazit sadu vysledku z obycejneho Selectu ktery je v SP, nechapu ale je to tak. V Mysql Query Browser dostanu 2 sady vysledku po 4 radcich ( 2 hraci - 4 zapasy ) coz je spravne.

Nyni bych k tomu mel nekolik otazek


1/ Jak to vypsat do PHPka , klasickym zpusobem to nejde ( $a = mysql_query("CALL RESULT()"; while ( ... ) )
2/ Jak bych mohl prostrcit do te procedury nekolik IDcek hracu , jedna se mi o toto id IN (1, 11); , jako bych proste v PHPku udelal array(1,2,3,4) a pak si to zpracoval, je na to v SP nejaky figl?
3/ Jak by tu SP napsal clovek, ktery SP ovlada a neuci se je jako ja a premysli proc je to tolik jine nez klasicke programovani :)

Diky Tome
Kcko
Profil
Tak na 1/ si opet odpovim sam ( mysql to neumi ale Mysqli uz ano )

na 2+3 si pockam :)
TomášK
Profil
Argh. Během dne jsem tu postupně tvořil odpověd, když mi tu něco běželo. Dopisoval jsem poslední řádek a vypadly pojistky... tak znova, aspoň to podstatné.

Ať dělám, co dělám, ten dotaz mi běží pro 1000 řádků vteřiny, pro 5 000 řádků už desítky vteřin až minuty. Zajímalo by mě, jestli za to třeba nemůže nějaký index, mohl bys poslat EXPLAIN toho dotazu? Tu je můj:

mysql> EXPLAIN SELECT
    -> (SELECT COUNT(*) + 1 FROM poradi as t1 WHERE t1.body > t2.body) AS rank, t2.tym, t2.body
    -> FROM poradi as t2;
+----+--------------------+-------+-------+---------------+----------+---------+------+------+--------------------------+
| id | select_type        | table | type  | possible_keys | key      | key_len | ref  | rows | Extra                    |
+----+--------------------+-------+-------+---------------+----------+---------+------+------+--------------------------+
|  1 | PRIMARY            | t2    | ALL   | NULL          | NULL     | NULL    | NULL | 5000 |                          | 
|  2 | DEPENDENT SUBQUERY | t1    | index | idx_body      | idx_body | 5       | NULL | 5000 | Using where; Using index | 
+----+--------------------+-------+-------+---------------+----------+---------+------+------+--------------------------+


Jinak pises ze nevis co by to tam mohlo byt z hlediska vypoctu slozite[/]
Špatně jsem se vyjádřil. Chtěl jsem říct, že ta chyba neovlivňuje délku výpočtu. Neměl jsem na mysli náročnost procedury.

K druhému dotazu:
[i]Potrebuji zjistit 4 posledni zapasy konkretnich hracu


Jedná se v podstatě o stejný problém, pro jeho řešení platí totéž co pro první otázku. Lze řešit pomocí uložené procedury (rozumně rychlé, spolehlivé), @proměnné (ještě rychlejší, nespolehlivé), korelovaného poddotazu, self joinu (ten tu ještě nepadl, ale šel by asi taky použít). A analytické funkce (PostgreSQL) to umí vyřešit elegantně v jedno selectu.

1, úžasné :) žil jsem v domnění, že tohle MySQL neumí vůbec. Buď jsem kdysi špatně hledal nebo se to v mezičase naučilo.
2, http://forums.mysql.com/read.php?98,90868 z roku 2006. Některé databáze umí posílat jako parametr cursor, v MySQL jsem to nenašel, myslím, že to spíš neumí. Nabízené řešení je tedy předávat to jako řetězec a parsovat to z něj nebo vytvořit pomocnou tabulku, předat jméno té tabulky a pomocí prepared statements z ní vydolovat potřebné.
3, Tu se necítím povolaný, neb se stále učím :) Napsal jsem všehovšudy jeden větší projekt, zato ve třech různých databázích (MySQL, Oracle, MSSQL). Myslím, že by člověk, který SP ovládá zvolil jinou databázi, pokud by měl tu možnost. Tam to řeší efektivně jeden select. MySQL na stejný problém nasazuje dočasnou tabulku, SP, prepaded statement. Z mého pohledu je MySQL dostatečné, pro jednodušší aplikace, v oblasti uložených procedur, transakcí apod. má ještě co dohánět. Mám pocit, že v MySQL vývoj postupuje (snad se nezastaví, když Sun přešel pod Oracle), ale v současném stavu tomu ještě něco chybí. Ale ber to s rezervou, odborníkem se být necítím.
Kcko
Profil
1/ No taky sem to chvili hledal :)
2/ Abych rekl pravdu toto reseni se mi tedy vubec nelibi ( narazil jsem na nej vcera taktez ) , radsi si ty promenne rozparsuji pomoci STR funkci az to budu potrebovat ( hloupa MYSQL )
3/ Tak urcite mas vic zkusenosti, jinak vidim ze jedna z rad je docasna tabulka, tak si ty data z cyklu poukladam do ni a pak provedu finalni select

Diky za pomoc a ochotu

PS. Ten explain Ti vecer hodim
PS2.
SET @minule := 0;
SET @poradi := 0;
SET @radek := 1;
SELECT 
    tym,
    body,
    @poradi := IF(@minule = body, @poradi, @radek) AS poradi,
    @radek := @radek + 1 AS radek,
    @minule := body AS tmp
FROM 
    poradi
ORDER BY
 body DESC;


Muzes zkusit zakomponovat do sveho dotazu UPDATE? ( Aby se to ocislovalo natvrdo, nedari se mi :/ , rad bych to videl )
TomášK
Profil
Zkušeností mám zřejmě víc, což ovšem neznamená, že neplácám blbosti, jen možná trochu menší než bys
řekl ty, ale pořád jsou to blbosti. Proto radši kecám do selectů, protože tuším, co od nich čekat,
ale nechci kecat do toho, jak správně psát proceduru, protože vím, že to nevím. :)

Tu je update:

SET @minule := 0;
SET @poradi := 0;
SET @radek := 1;
UPDATE 
    poradi, 
    (
        SELECT 
            tym,
            body,
            @poradi := IF(@minule = body, @poradi, @radek) AS poradi,
            @radek := @radek + 1 AS radek,
            @minule := body AS tmp
        FROM poradi
        ORDER BY body DESC 
    ) AS vypocet
SET poradi.poradi = vypocet.poradi 
WHERE poradi.tym = vypocet.tym;
Kcko
Profil
1/


INDEX
Zobrazeny záznamy 0 - 29 (10 000 celkem, Dotaz zabral 0.2150 sekund)

id 	select_type 	table 	type 	possible_keys 	key 	key_len 	ref 	rows 	Extra
1 	PRIMARY 	t2 	ALL 	NULL 	NULL 	NULL 	NULL 	9751 	 
2 	DEPENDENT SUBQUERY 	t1 	ALL 	NULL 	NULL 	NULL 	NULL 	9751 	Using where





2/
BEZ INDEXU

Zobrazeny záznamy 0 - 29 (10 000 celkem, Dotaz zabral 0.2087 sekund)

id 	select_type 	table 	type 	possible_keys 	key 	key_len 	ref 	rows 	Extra
1 	PRIMARY 	t2 	ALL 	NULL 	NULL 	NULL 	NULL 	10426 	 
2 	DEPENDENT SUBQUERY 	t1 	ALL 	NULL 	NULL 	NULL 	NULL 	10426 	Using where


SELECT SQL_NO_CACHE
   (SELECT COUNT(*) + 1 FROM poradi as t1 WHERE t1.body > t2.body) AS rank, t2.tym, t2.body
    FROM poradi as t2




Prijde mi to proste hrozne rychle ...



Jinak diky za update ale moc nefunguje, kazdemu tymu nasadi poradi "1"

PS. Mozna bychom to tu nemuseli dale resit, soukromne ? Nebo si obcas profesne napsat? :) Kontakt mam v profilu ( email / ICQ / msn )
Kcko
Profil
PS2. Omlouvam se, mel sem vsecky ID Tymu jako 0 boze !!!
TomášK
Profil
1, Zobrazeny záznamy 0 - 29
bodejť by to nebylo rychlé, očísluje prvních 30 záznamů a o zbytek se nestará :) Phpmyadmin ti automaticky doplní limit 0, 30, pokud mu tam nic nezadáš. Doplň tam LIMIT 0, 10 000 a dostaneš se na mé časy.

2, Update jsem zkoušel a mě funguje - což je přesně důvod, proč @proměnným moc nevěřím - můžou se chovat pokaždé jinak - zřejmě máš jinou verzi MySQL nebo jinou konfiguraci. Netuším, co změnit, aby ti to taky fungovalo. Možná prohodit pořadí řádků, přidat k @minule = body nějakou ohavnost jako umocnit na druhou a odmocnit, aby se to počítalo dýl (jenom za to, že jsem tohle řekl nahlas si uděluju tři prasátka:) ) nebo zkusit černou magii. Podobné bugy bývají docela zákeřné - přehraješ aplikaci na jiný server a najednou to přestane fungovat.

Na ICQ (jabberu) teď cíleně nejsem, mohli bychom to řešit po mailu, pokud se ti to zdá o hodně lepší, ale mě zdejší diskuze docela vyhovuje. Mám pocit, že necháváme odkaz budoucím generacím - až někdo bude googlit stejné problém, bude mít radost, až to najde, mail by zanikl v historii dějin. Plus tu vidím několik výhod, že až plácnu něco úplně mimo, tak třeba přijde někdo chytřejší a řekne mi to :) A taky se tu cítím svobodněji ve smyslu, že nemusím odpovídat (pokud bych z nějakého důvodu nechtěl/nemohl) a většinou se najde někdo jiný, kdo odpoví...

Edit: neměl jsem tu tvůj poslední post, když jsem to psal. Škoda, takový dobrý argument proti @proměnným mi to dalo:)
Kajman_
Profil *
Co to pořadí vypočítat přes dva updaty. Jednou normálně s rankem, jak je ve faq - jedinečné pořadí. Pak druhý update, který zgrupuje stejněbodové týmy a vybere u nich min?
Kcko
Profil
TomášK

1/ A joo :) no hezky sem se predvedl

2/ Vyreseno ( moje chyba vsechny tymy mely ID 0 )

add kontakt) Ok beru to :)


Kajman_

Tak zkus :)


Jinak to uz asi uzavreme, myslim ze jsme vyzkouseli snad vse
Kajman_
Profil *
Jedinečné pořadí určitě zvládneš.

Druhý update by mohl být...

update tabulka,
       (select body1, body2, body3, min(poradi) poradi
        from   tabulka
        group  by body1, body2, body3
        having count(*) > 1) as vypocet
set    tabulka.poradi = vypocet.poradi
where  tabulka.body1 = vypocet.body1
       and tabulka.body2 = vypocet.body2
       and tabulka.body3 = vypocet.body3


Rychlost asi výrazně ovlivní složený index (body1,body2,body3)
Kcko
Profil
Kajmane diky, jeste sem to nezkusil, ale uz jen tak od pohledu body1, body2, body3 to je co? To moc neodrazi nas priklad ... ?
Kajman_
Profil *
Mam vypis tymu, sesortovany podle urcitych parametru ( body, vstrelene goly, obdrzene goly atd.)

Do příkladu asi stačí dát jen body jedny.
Kcko
Profil
Aha promin, jasne, jdu to vyzkouset.
Kcko
Profil
Kajmane, opet musim smeknout.

Diky oboum zucastnenym o obohaceni :-)
TomášK
Profil
I já děkuju Kajmanovi za obohacení, dva updaty mě nenapadly. Jednoduché, rychlé...myslím, že mi tahle idea ještě hodněkrát ušetří psaní procedur :)

Vaše odpověď


Prosím používejte diakritiku a interpunkci.

Ochrana proti spamu. Napište prosím číslo dvě-sta čtyřicet-sedm:

0