ugrás a tartalomhoz

mysql, ket ertek maximuma

ErdosJ · 2007. Okt. 29. (H), 14.57
sziasztok
elovettem a mysql-t, a subquerykkel buveszkedtem, de most egy reszletnel elakadtam.
konkretan ket vagy tobb ertek kozul a legnagyobbat szeretnem visszakapni. olyan modon, mint ahogyan ezt mas nyelvekben a max(), Math.max() fugvenyekkel meg lehet oldani. elsore a MAX()-ra gondoltam, de -mint kideult- ez nem ere valo.
mit javasoltok? van erre beepitett megoldas, vagy nekem kell irnom egyet? hogyan celszeru nekiallni?
valaszaitokat varom
ErdosJ
 
1

pedig arra való

virág · 2007. Okt. 29. (H), 15.28
Szia, valamit elnézhettél, mert a MAX() arra való:

http://dev.mysql.com/doc/refman/5.0/en/group-by-functions.html#function_min
2

Re: pedig arra való

ErdosJ · 2007. Okt. 29. (H), 15.34
hmm.. az a baj, hogy en ugy szeretnem hasznalni, hogy pl: MAX(32,128)...
ezt viszont nem engedi, csak a MAX(oszlop) kodot, ahol pedig az 'oszlop' oszlop legnagyobb ertekevel ter vissza. csakhogy nekem nem ez kell.
3

egyik lehetseges megoldas

ErdosJ · 2007. Okt. 29. (H), 15.36
most azon kiserletezem, hogy a ket szamot elobb union-nal egy oszlopba rendezem, es azon vegrehajtani.. de nem mukodik..
4

egyik lehetseges megoldas

ErdosJ · 2007. Okt. 29. (H), 16.48
idaig mar eljutottam.
(select 32 as s) union (select 128 as s)
a kovetkezo viszont mar nem jo:
max((select 32 as s) union (select 128 as s))
miert nem? mit rontottam el? hogyan lehetne megis mukodesre birni?
5

temp tábla

virág · 2007. Okt. 29. (H), 17.17
Szia, temporary táblával nem próbálkoztál?
6

megoldas -vegleges

ErdosJ · 2007. Okt. 29. (H), 17.32
szia
agyuval meg nem estem a verebnek, koszonom, de a megoldas mar megvan.
tehat:

SELECT MIN(m)
   FROM (
    SELECT 32 AS m
    UNION
    SELECT 1024 AS m
   ) AS aliasm
tovabba:
http://www.prog.hu/tudastar/73513-8/A+mysql+maximum+minimum.html
7

stored function

winston · 2007. Okt. 29. (H), 20.33
nem tudom, hogy hány számot, vagy honnan akarsz összehasonlítani, de ha standard kettő közül próbálod eldönteni, akkor:
CREATE FUNCTION bigger (a INTEGER, b INTEGER) RETURNS INTEGER
	DETERMINISTIC
BEGIN
	IF a > b THEN
		RETURN a;
	ELSE
		RETURN b;
	END IF;
END
és utána
SELECT bigger(4, 3)
8

Off: nagyon rákattantál...

janoszen · 2007. Okt. 29. (H), 21.04
Nagyon rákattantál Te is a tárolt eljárásos témára. :)
9

hasznos

winston · 2007. Okt. 29. (H), 21.13
hát mit tagadjam, az utóbbi időben végre sikerült eljutdom eddig is, előtte már rég akartam. de hasznos nagyon. érdemes ráfordítani az időt és energiát.
11

ezt minek tárolt eljárásba?

Hodicska Gergely · 2007. Okt. 29. (H), 23.24
Használhatsz if-et simán a selectben is, ilyesmire talán kicsit túlzás függvényt írni.


Üdv,
Felhö
12

tátolt > gyorsabb

winston · 2007. Okt. 30. (K), 08.44
amik miatt függvényként gondoltam: tároltként gyorsabb, a determinisztikusság miatt, és hogy csak egyszer kelljen "sokat" gépelni. amúgy meg nem hinném, hogy túlzás, nem egy olyan nagy függvény ez, hogy hatalmas munka legyen.

szép napot
w.
15

nem hiszem, hogy gyorsabb lenne

Hodicska Gergely · 2007. Okt. 30. (K), 12.38
Az oké, hogy determinisztikus, de hiszem, hogy a paraméterek alapján előkeresni a már kiszámolt értéket gyorsabb, mint összevetni két számot. Plusz ilyenkor is azért kell legyen valami járulékos költsége a tárolt eljárás meghívásának.


Üdv,
Felhő
16

fenntartom

winston · 2007. Okt. 30. (K), 19.15
a tárolt eljárás hívására nem tudok plusz költséget. mivel tárolt: előre parseolt, stb. nem kell újra parseolni. és igen: determinisztikus. mondjuk egyébként nem egy nagy költségű függvényről van szó, és már lentebb találtak beépített megoldást (ami annyiban jobb is, hogy nem csak 2-őt hasonlít össze), de mindenesetre fenntartom a fenti érveket, mint előnyök a sima select-el szemben.
17

gondold át

Hodicska Gergely · 2007. Okt. 31. (Sze), 00.20
Mindkét esetben meghívsz egy függvényt. Az egyik esetben egy belső függvényről van szó, a másik esetben egy tárolt eljárásról, ami minimum annyiba kerül, mint az előbbi, bár szerintem biztosan kicsit lassabb, hisz ha más nem, akkor pl. jogosultság ellenőrzésreszükség van. Ezután az if esetében összehasonlít két számot, majd ettől függően visszaad egy értéket. A másik esetben is ennek meg kell történni, de előtte kell egy lookup annak megállapítására, hogy adott paraméterekkel már meg lett-e hívva a tárolt eljárás. Ennek fényében a tárolt eljárás szükségszerűen lassabb kell legyen.


Üdv,
Felhő

u.i.: Megkockáztatom, hogy jelen esetben a DETERMINISTIC még talán lassít is, de ezt le kell tesztelni.

Szerk:

mysql> select benchmark(100000, (select bigger(6,5)));
+-----------------------------------------+
| benchmark(100000, (select bigger(6,5))) |
+-----------------------------------------+
|                                       0 |
+-----------------------------------------+
1 row in set (0.45 sec)

mysql> select benchmark(100000, (select if(6>5,6,5)));
+-----------------------------------------+
| benchmark(100000, (select if(6>5,6,5))) |
+-----------------------------------------+
|                                       0 |
+-----------------------------------------+
1 row in set (0.01 sec)
18

benchmark

winston · 2007. Okt. 31. (Sze), 09.58
a benchmark-al valóban nincs mit vitatkozni, ez tény. az általános tapasztalatom azt mutatta, hogy tárolt eljárás hívása gyorsabb. ebben az esetben (a lekérdezés egyszerűsége miatt) végülis nem működött, és igen, elkövettem azt a hibát, hogy nem mértem ki, csak az ismeretekre, és a megérzésemre hagyatkoztam. mindenesetre azt tartom, hogy a tárolt eljárás hasznos dolog, ha bonyolultabb dolgot csinál az ember.
19

deterministic

winston · 2007. Nov. 2. (P), 10.45
most egyéb dolgok miatt épp hasonlót teszteltem, gondoltam megosztom az eredményeket:
mysql> SELECT BENCHMARK(1000000, (SELECT BIGGER(10, 100)));
+----------------------------------------------+
| BENCHMARK(1000000, (SELECT BIGGER(10, 100))) |
+----------------------------------------------+
|                                            0 | 
+----------------------------------------------+
1 row in set (32.63 sec)

mysql> SELECT BENCHMARK(1000000, (SELECT BIGGER_2(10, 100)));
+------------------------------------------------+
| BENCHMARK(1000000, (SELECT BIGGER_2(10, 100))) |
+------------------------------------------------+
|                                              0 | 
+------------------------------------------------+
1 row in set (39.40 sec)


mysql> SELECT BENCHMARK(1000000, (SELECT if(10>100,10,100)));
+------------------------------------------------+
| BENCHMARK(1000000, (SELECT if(10>100,10,100))) |
+------------------------------------------------+
|                                              0 | 
+------------------------------------------------+
1 row in set (0.34 sec)

mysql> SELECT BENCHMARK(1000000, (SELECT GREATEST(10, 100)));
+------------------------------------------------+
| BENCHMARK(1000000, (SELECT GREATEST(10, 100))) |
+------------------------------------------------+
|                                              0 | 
+------------------------------------------------+
1 row in set (0.24 sec)
a BIGGER_2 az, ahol nincs DETERMINISTIC, a BIGGER-ben van. (megjegyzés: többször lefuttattam, és nem mindig ez volt a sorrend a két bigger között, de legtöbbször igen) a fentiekből világosan látszik, hogy a GREATEST (a beépített) a legjobb megoldás. (ami mondjuk érthető is)
10

greatest

Rici · 2007. Okt. 29. (H), 22.58
Amit keresel, azt nem kell külön megírni, beépített függvényként létezik. A neve greatest.
13

Re: greatest

ErdosJ · 2007. Okt. 30. (K), 09.57
fuu, nagyon koszonom!
pont ilyet kerestem. bar mar sikerult a kereket ujbol feltalalnom...
14

énis köszi!

virág · 2007. Okt. 30. (K), 10.31
Mit én kerestem ezt tegnap a MySQL doksiban...vak vagyok! :)