ugrás a tartalomhoz

Keresés mysql view-ban

iddqd · 2012. Júl. 19. (Cs), 12.13
Sziasztok,

Lenne egy kérdésem hozzátok. Van 3 különböző táblám egy csoportban ( tagok adatai,
tagok előfizetései, tagok képei ). Ezek összességéből kb 9 oszlop az ami adja a lekérdezéseim ( amik erre vonatkoznak ) 80% -át. Ezért készítettem ezeknek egy view táblát, megspórolva a join -okat, ami tartalmazza a 3 tábla szükséges sorait plusz 1-2 származtatott adatot. Viszont nem az egész táblát hívom le, a lekérdezéseknek is van 1 - 2 feltétele, szűrni kell a találatokat város szerint, előfizetés típusa szerint stb. Szinte mindegyik mező alapján érkezne feltétel.
Mennyire alkalmas a view -erre? Illetve mennyire jó egyáltalán ez az elképzelés?
Esetleg érdemesebb lenne minden feltételnek megfelelően egy view -t készíteni?
Köszi.
Üdv!
‹ #1036 - Table 'kategoriak' is read only Lekérdezésnél eggyel kevesebb találatot mutat ›
 ■
1

View

Hidvégi Gábor · 2012. Júl. 19. (Cs), 13.26
A View szerintem arra jó, hogy bizonyos adatbázis felhasználóknak (általában) olvasási jogot adjunk bizonyos adatokhoz, de úgy, hogy ne láthassák a teljes táblákat, amikből a View-k táplálkoznak. Tudomásom szerint a View virtuális dolog, és a háttérben a saját lekérdezése fut le, amikor lekérdezel belőle.

Wikipedia – alátámasztja, amit írtam.

Ha erre nincs szükséged, akkor szerintem csak overhead-et okoz egy egyszerű SELECT-hez képest.
2

Ezek alapján jött az ötlet:

iddqd · 2012. Júl. 19. (Cs), 14.30
Views can join and simplify multiple tables into a single virtual table.

A view can be used to 'pre-process' joins, making life easier when you create queries - you don't have to set up the joins between the underlying tables again and again.

Hasznos lenne nekem ez a megoldás csak nem tudom, hogyan viselkedik élőben, de én is úgy érzem hogy kicsit sántít. Olvasgatok még egy kicsit... :)
3

Nem vagyok jártas MySQL-ben,

kuka · 2012. Júl. 19. (Cs), 14.52
Nem vagyok jártas MySQL-ben, de PostgreSQL esetében annak a „pre-process” kifejezésnek a jelentéséhez az is hozzátartozna, hogy a view-k parse-olva tárolódnak, tehát tábla, mező és a többi neve helyett OID-ekkel. Emellett például a coalesce() hívások is case-ként vannak tárolva. Ezért a view-ból való lekérdezés sebessége közelebb lesz a prepared statementhoz. Ebből kiindulva, ahol egy sima select és egy prepared statement sebesség különbsége indokolttá tenné az utóbbi használatát, ott létjogosultnak találom egy view használatát is. Különben csak a hibakeresést bonyolítja. De ez szigorúan személyes vélemény és teljes mértékben PostgreSQL tapasztalatokra épül.
4

Lassú a SELECT?

Pepita · 2012. Júl. 20. (P), 02.20
Sima SELECT-el (és join) túl lassú a lekérdezésed?
Csak azért kérdem, mert ahhoz min. 10^6 nagyságrendű rekord kell, vagy vmi mást elrontottál. Itt felhasználókról írsz, azok száma (és csatolt részeiké) ritkán több néhány 100000-nél. Tehát jónak kéne lennie view nélkül. Csak gondolom, hogy MySql-nél beállításoktól függ, hogy hogy kezeli a view-t. Ha spórolni akarsz (időt) akkor mindenképp a feltételek szerinti több view lesz a megoldás. Viszont nem tudom, hogy a view táblák hol és hogyan tárolódnak, mi van, ha nem férnek el RAM-ban. Félek akkor még lassabbra is kijöhet a vége, mint néhány join-al.
5

Egyszer belefutottam abba a

deejayy · 2012. Júl. 20. (P), 07.57
Egyszer belefutottam abba a problémába (mysql specifikus), hogy ha egy view-nak adok where feltételeket, akkor lassabban fut le, mintha beírnám query-ként az egész selectet (amiből a view felépül) és ott toldanám meg a where-t. Ennek - gondolom - az az oka, hogy először fetcheli le magának a teljes view eredményét, és csak utána szűri meg a where feltételek alapján. Szóval erre érdemes figyelni.

Meg ami mindenképpen megfondolandó az az, hogy az összes join on feltételben szereplő mezőknek legyen indexe, illetve a where feltételben érintett mezőkkel is érdemes kisérletezni ily módon.
7

deejayy:

iddqd · 2012. Júl. 20. (P), 11.06
Igen, ettől a lehetséges problémától tartok én is! Az a része teljesül természetesen, hogy az érintett mezők indexeltek az eredeti táblában, de szerintem ez max a view összeállításában segít, a nézettáblán később végrehajtott keresésekben már nem. Vagy rosszul gondolom?
Hm.. de igazából egyikőtök sem igazán buzdít rá, hogy ez egy jó ötlet lenne.
8

Materialised views

complex857 · 2012. Júl. 20. (P), 11.40
Egy korábbi kérdésre érkezett válaszban említették az oracle féle materialised view portjat mysql -re, ez esetleg segíthet a teljesítményproblémákon.

http://code.google.com/p/flexviews/
9

Én első körben inkább egyéb

eddig bírtam szó nélkül · 2012. Júl. 20. (P), 11.57
Én első körben inkább egyéb úton kísérleteznék az optimalizálással. A materialized view eredendően adattárházak számára lett kitalálva, óriási adatbázisokhoz.
Pár tíz-, százezres tábláknál nem biztos, hogy jó ötlet, mert bizonyos lekérdezéseket gyorsít, más műveleteket meg jelentősen lassíthat.
10

Az lehet, hogy nem

deejayy · 2012. Júl. 20. (P), 14.55
Az lehet, hogy nem buzdítottalak, azért én fenntartásokkal ugyan, de használok view-kat. Mindig mérek, lekérdezési időt, php futásidőt, ha valami gond van, azonnal látom. Néha generálok reális mennyiségű tesztadatot, stb, stb.

A view-k szerintem hasznos dolgok.
11

Köszönöm mindenkinek!

iddqd · 2012. Júl. 20. (P), 16.26
Kevés az időm most rá, de neki ülök kipróbálom azért és lemérem. Elvileg "kevés" adattal is kellene látnom a különbséget a futási időben, ami nyilván nagyobb terhelés alatt és több adattal arányosan nő. Jól gondolom?
Hogyan érdemes mérni? Explain -el a lekérdezést és a php -val együtt külön a komplett folyamatokat? Milyen módszerekkel érdemes?
Még egyszer köszi mindenkinek a rám szánt idejét!
13

Nem biztos

Pepita · 2012. Júl. 21. (Szo), 05.14
Elvileg "kevés" adattal is kellene látnom a különbséget a futási időben, ami nyilván nagyobb terhelés alatt és több adattal arányosan nő
Ebben én nem lennék olyan biztos, mert egy csomó olyan - viszonylag állandó - idő is van, ami csak lekérdezésenként n-szer "számolandó", függetlenül az adatmennyiségtől. Plusz lehetnek olyan lassulások is, amik n adatmennyiség felett megugranak. Tehát mindenképp közel azonos rekordszámmal kell kísérletezni, generáld ezt progiból.

Nem jut eszembe konkrétan, de biztos van mysql fv., amivel egyszerűen megtudhatod a legutóbbi lekérdezés idejét. Ha több lekérdezés van egy folyamatban, akkor mind után kérdezd le, add össze, stb. Legtöbbször a legegyszerűbb a legjobb. Mérheted a php futásidőt is, ebből levonod a mysql-t, az a "tiszta" php idő.
12

Jól gondolod.

Pepita · 2012. Júl. 21. (Szo), 05.06
ez max a view összeállításában segít, a nézettáblán később végrehajtott keresésekben már nem
Így van. Az eredeti indexeknek - tudtommal - semmi közük nem lehet a view-hoz, mert az már egy másik tábla.
Nincs nálam könyv, így csak kérdezem: view-nak nem lehet véletlenül indexeket létrehozni? Az lenne a jó megoldás, már ha kell view.
14

Oracle.

deejayy · 2012. Júl. 22. (V), 19.41
Oracle.
6

Nem teszteltem

iddqd · 2012. Júl. 20. (P), 10.56
Nem próbáltam még ki, egyik verziót sem, az alap ötlet az egyszerűsítés lenne és a sebesség. Ezért gondoltam hogy ha ezekre az adatokra van szükségem általában, akár lehet ez egy jó megoldás. A tesztem se lenne mérvadó, localhost -on és azzal 20 - 30 record -al amit most hirtelen fel tudnék vinni, gondolom itt nem ütközne ki a valós hátrány, ha van. De azért kipróbálom EXPLAIN -el, hogy mit mond már csak kíváncsiságból.