- OLED TV topic
- Melyik tápegységet vegyem?
- VR topik (Oculus Rift, stb.)
- 3D nyomtatás
- Kormányok / autós szimulátorok topikja
- Sugárkövetés nélküli sugárkövetés felé menetel az új PlayStation
- Fejhallgató erősítő és DAC topik
- NVIDIA GeForce RTX 5080 / 5090 (GB203 / 202)
- Androidos fejegységek
- TCL LCD és LED TV-k
Új hozzászólás Aktív témák
-
bpx
őstag
válasz
don_peter
#1731
üzenetére
Feltételeztem, hogy olyan eset nem fordul elő, hogy egy fórum üzenethez nem létezik user (mert usert általában nem törlünk, csak inaktiválunk), és így nem kell ezek közé is outer join, de egyébként igen.
Ezen kívül, ha van rá igény, azt kellene még megcsinálni, hogy a topikonként a legújabb hozzászólás dátumát és felhasználóját helyesen összegyűjteni, mert egy ilyen GROUP BY-t egy szigorúbb adatbáziskezelő (pl. DB2, MSSQL, Oracle) kapásból visszadob hibával, mert nem determinisztikus az eredmény. (Azt, hogy a MySQL egyáltalán megenged ilyet, én inkább hiányosságnak tartom, mint feature-nek - OK, kikapcsolható ez a működés.)
MySQL-ben sajnos nincsenek analitikus függvények, helyette vannak ilyen kerülő megoldások:
Végül limitálni kellene, hogy hány sort kapunk vissza, hogy ne dolgozzon esetleg feleslegesen az adatbázis, és gondolom a felhasználónak sem a létező összes, akár több száz, ezer topikot rakod ki felületre, hanem csak egy fix mennyiséget, ahogy pl. itt a prohardveren is működik.
-
bpx
őstag
válasz
don_peter
#1729
üzenetére
Ha azok a topikok kellenek, amelyekben nincs hozzászólás, akkor miért a forum_uzenetek van a LEFT JOIN bal oldalán?
forum_uzenetek fu
LEFT JOIN topik t
ON fu.topik_id = t.idEz azt jelenti, hogy azokat fórum üzeneteket is kéred, amelyek egyik topikhoz sem tartoznak.
forum_uzenetek LEFT JOIN topik + UNION bonyolítás helyett nem egyszerűbb lenne a topik LEFT JOIN forum_uzenetek?
-
don_peter
senior tag
válasz
don_peter
#1728
üzenetére
No ez már jó
Hátha tudok vele segíteni...
Aki tud ennél egyszerűbb megoldást az kérem ossza meg velem.
Köszönöm.SELECT * FROM
(SELECT * FROM
(SELECT t.id, t.title, fu.datum, u.nick
FROM forum_uzenetek fu
LEFT JOIN topik t
ON fu.topik_id = t.id
JOIN users u
ON u.id = fu.user_id
WHERE t.topik_csoport_id = 9
ORDER BY fu.datum DESC) AS a
UNION
SELECT t.id, t.title, "1970-01-01" as datum, NULL as nick
FROM topik t
where t.topik_csoport_id = 9
) c
GROUP BY id ORDER BY datum DESC -
don_peter
senior tag
válasz
don_peter
#1727
üzenetére
Nos kicsi átalakítással már működik is és elég gyors 0.1mp-es lefutási időt produkál.
SELECT * FROM
(SELECT * FROM
(SELECT t.id, t.title, fu.datum, u.nick
FROM forum_uzenetek fu
LEFT JOIN topik t
ON t.id = fu.topik_id
JOIN users u
ON u.id = fu.user_id
WHERE t.topik_csoport_id = 9) as a
GROUP BY a.id
UNION
SELECT t.id, t.title, "1970-01-01" as datum, NULL as nick FROM topik t where t.topik_csoport_id = 9) c
GROUP BY id ORDER BY datum DESCKöszi a segítséget és az elvi rávezetést...
ui: öhh, még sem jó..
Nem jól szelektálja az utolsó bejegyzéseket.
Ennek még utána nézek.. -
#1726
Apollo17hu
őstag
don_peter
#1725
Apollo17hu
őstag
válasz
don_peter
#1725
üzenetére
Az előbb lehet, hogy részben hülyeséget írtam, de valahogy így gondoltam:
SELECT c.* FROM
((SELECT a.id, a.title, a.datum, a.nick FROM
(SELECT t.id,
t.title,
fu.datum,
u.nick
FROM forum_uzenetek fu
LEFT JOIN topik t
ON t.id = fu.topik_id
JOIN users u
ON u.id = fu.user_id
WHERE t.topik_csoport_id = 9) AS a
GROUP BY a.id) b
UNION
(SELECT t.id, t.title, 1000-01-01 as datum, NULL as nick FROM topik t) seged) c
GROUP BY c.id
ORDER BY c.datum DESC...tehát minden topikhoz létrehozol egy 1000-01-01 dátumra vonatkozó hsz.-t, ami csak akkor számít a sorrendben, ha nincs rajta kívül más hsz. (tehát ha üres a fórumtéma).
-
#1715
Apollo17hu
őstag
don_peter
#1714
Apollo17hu
őstag
válasz
don_peter
#1714
üzenetére
Akkor két allekérdezés kell:
- az egyikben listázod topikonként a legfrissebb hsz.-ek dátumát,
- a másikban pedig leszeded topikonként a userek legfrissebb hsz.-eit.Ezt a kettőt topik-topik és dátum-dátum kötéssel kötve ezt kapod:
SELECT topik_datum.title,
topik_user_datum.nev,
topik_datum.updatum
FROM (SELECT t.id AS tid,
t.title AS title,
MAX(fu.datum) AS updatum
FROM forum_uzenetek AS fu,
topik AS t
WHERE fu.topik_id = t.id
GROUP BY t.id,
t.title) AS topik_datum,
(SELECT t.id AS tid,
u.nick AS nev,
MAX(fu.datum) AS updatum
FROM forum_uzenetek AS fu,
topik AS t,
users AS u
WHERE fu.topik_id = t.id
AND u.id = fu.user_id
GROUP BY t.id,
u.id) AS topik_user_datum
WHERE topik_datum.tid = topik_user_datum.tid
AND topik_datum.updatum = topik_user_datum.updatum
ORDER BY topik_datum.updatum DESC LIMIT 8Hogy milyen gyorsan fut le, az jó kérdés, de analitikus függvények nélkül ennél jobbat nem tudok.
-
#1711
Apollo17hu
őstag
don_peter
#1709
Apollo17hu
őstag
-
#1707
Apollo17hu
őstag
don_peter
#1706
Apollo17hu
őstag
válasz
don_peter
#1706
üzenetére
MySQL tud analitikus függvényeket? Ha igen, akkor én valahogy így csinálnám:
SELECT x.*
FROM (SELECT t.id AS tid,
t.title AS title,
fu.datum AS updatum,
u.nick AS nev
rank() OVER (PARTITION BY t.id ORDER BY fu.datum DESC) AS sorrend
FROM forum_uzenetek AS fu,
topik AS t,
users AS u
WHERE fu.topik_id = t.id
AND u.id = fu.user_id) AS x
WHERE x.sorrend = 1Amúgy az a nyolcas limit mi akar lenni a lekérdezéseidben?
-
don_peter
senior tag
válasz
don_peter
#1705
üzenetére
Gondolok itt ilyesmire:
SELECT t.id AS tid,
t.title AS title,
MAX(fu.datum) AS updatum,
u.nick AS nev
FROM forum_uzenetek AS fu,
topik AS t,
users AS u
WHERE fu.topik_id = t.id AND u.id = fu.user_id
GROUP BY t.id,
t.title
u.id
ORDER BY `updatum` DESC LIMIT 8Vagy ezt tovább már nem lehet feszegetni?
-
#1704
Apollo17hu
őstag
don_peter
#1698
Apollo17hu
őstag
válasz
don_peter
#1698
üzenetére
Ha topikonként a legfrissebb bejegyzésre van szükséged, akkor valahogy így kellene:
SELECT t.id AS tid,
t.title AS title,
MAX(fu.datum) AS updatum
FROM forum_uzenetek AS fu,
topik AS t
WHERE fu.topik_id = t.id
GROUP BY t.id,
t.titleEz mondjuk nem MySQL, de a kétszeri sorbarendezést (ORDER BY) kiváltja egy aggregáló függvény, ami valószínűleg gyorsít rajta.
-
-
martonx
veterán
válasz
don_peter
#1683
üzenetére
Segítettem is, sőt szerintem az én segítségem lesz a leghasznosabb, hiszen közel nulla ráhatásod van a dologra, így a szolgáltató kezében vagy, és én pont oda irányítottalak.
De ha már csak egy pici részletet is mutattál a kódodból, akkor az ember hagy tegyen finom utalást annak szakmaiatlan mivoltára. Ezen be lehet sértődni és mindent hagyni ugyanúgy (elvégre sok légy nem tévedhet), vagy pozitívan is lehet fogadni, és meg is lehet írni normálisra. -
martonx
veterán
válasz
don_peter
#1677
üzenetére
"Milyen izé, és milyen ledegradáló jelző az, hogy tákoltad.?"
Bocsi, akkor meg is van, hogy ki tákolta, össze, te. A kódot látva az a legkisebb baj, hogy miért lett most lassú. Sőt inkább azon csodálkozok, hogy miért nem volt lassú eddigDe, hogy konstruktív is legyek, tényleg nézd meg az indexeket, illetve én jelezném az üzemeltetőnek, hogy nagyságrendekkel lassabb lett az új mysql, és konfigolják be normálisan legyenek szívesek.
-
sonar
addikt
válasz
don_peter
#1679
üzenetére
Az időt általában a program irja ki alul. Ilyesmit kell keresned, hogy query executed, row set... és többnyire ms-ben (milisec) vagy rosszabb esetben sec -ben irja ki.
Mi a közvetlen felület nálad?
command line mysql? v phpmyadmin? query browser, workbenchazt még meg tudod nézni, hogy az indexeket használja-e.
-
-
sonar
addikt
válasz
don_peter
#1674
üzenetére
Szúrd be az EXPLAIN-t a query-d elé és meglátod, hogy mennyi idő alatt fut le és mennyi sort vizsgál át.
Igy ha módositgatsz, könnyebben össze tudod hasonlitani az eredményeket.
Szedd szét darabokra a query-t és nézd meg, hogy melyik a leglassabb aztán lehet gondolkodni tovább -
don_peter
senior tag
válasz
don_peter
#1673
üzenetére
A példában látható, hogy a fő formon belül van egy subselect.
A subselecthez érve az SQL egy újabb ciklusba kezd amely addig fut amíg kigyűjti, hogy az adott fórumbejegyzést író felhasználónak mennyi az eddigi összes bejegyzéseinek száma.
Amikor ez megvan akkor tovább lép és folytatja a parancsok végrehajtását.
Eddig ez a lekérdezési forma tökéletes és gyors volt, de most állítólag az új verzió élesítésével a rendszer korlátozza az erőforrásigényeket ezért tapasztalható a lassulás.
Tény és való, hogy van olyan felhasználó akinek több mint 5e bejegyzése van és ekkora számú rekordnál már ez a fajta struktúra erőforrás pocséklónak tűnhet.
A példa nem az eredeti adatbázist tükrözi, de a struktúra megegyezik.Váram megtisztelő javaslataitokat és segítségeteket.
Új hozzászólás Aktív témák
Hirdetés
- GYÖNYÖRŰ iPhone 13 Pro 256GB Graphite -1 ÉV GARANCIA - Kártyafüggetlen, MS3356
- GYÖNYÖRŰ iPhone 15 Plus 128GB Black -1 ÉV GARANCIA - Kártyafüggetlen, MS3355, 100% Akkumulátor
- GYÖNYÖRŰ iPhone 15 Plus 128GB Pink -1 ÉV GARANCIA - Kártyafüggetlen, MS3354
- Sony a6700 + Sigma 30mm 1.4 DC DN - új fotoplus vásárlás
- GYÖNYÖRŰ iPhone 15 Plus 128GB Pink -1 ÉV GARANCIA - Kártyafüggetlen, MS3353
- Bezámítás! Lenovo Thinkpad T14 Gen 5 üzleti - Ultra 7 165U 16GB DDR5 512GB SSD Intel Graphics WIN11
- ÁRGARANCIA! Épített KomPhone i5 13400F 16/32/64GB RAM RTX 3060 12GB GAMER PC termékbeszámítással
- Acer TravelMate P214 i3-1115G4 12GB 256GB 14" FHD 1év garancia
- Azonnali készpénzes INTEL CPU AMD VGA számítógép felvásárlás személyesen / postával korrekt áron
- Xiaomi 12T Pro 8/256 GB kék / 12 hó jótállás
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft.
Város: Budapest
Cég: FOTC
Város: Budapest