IRATKOZZ FEL
CSATORNÁNKRA
Az egyik oldalon sikeres optimalizáció gyakran okoz a másik oldalt lassulást. Például az indexek alkalmazása miatt a visszakeresés gyors lesz, de a beszúráshoz és frissítéshez kapcsolódó műveletek pedig lassabbak lesznek. A normalizált séma egyes kéréseket felgyorsít, míg másokat lelassít. A számláló és összegző táblák létrehozása egy jó ötlet a performancia javítására, de így az adatok karbantartása viszont nehézkesebb lesz. Fejlesztői szemmel nézve kell szemlélni az üzleti elvárásokat.
Sémahasználat és indexek
Jóllehet akik megfogalmazták és nem szakértők nem látják az igényük során felmerülő performancia problémákat. A séma és indexek létrehozásakor az egész rendszert kell vizsgálni, mivel kihatással vannak a rendszer többi részére is. A lekérdezések optimalizálásával és az szerver finomhangolásával is tisztában kell lennünk, hogy az indexek kialakításánál is jó döntéseket tudjunk hozni. Az adattípusok helyes megválasztása szintén hatással van a sebességre.
Az erre vonatkozó követendő alapelvek a következőek:
- Használjunk mindig annyi helyet amennyi szükséges az adatainkhoz. A kisebb adattípus feldolgozása gyorsabb, mert kevesebb helyet foglal a memóriában, a lemezen, kevesebb CPU ciklust igényelhet stb.. A későbbiek során, ha nagyon szükséges utólag lehet rajta állítani. (a tervezés korai szakaszában)
- Az egyszerűbb jobb, az integer adattípus összehasonlítása gyorsabb, mint a karakter típusé. Ha lehet használjuk azt, illetve a beépített mysql adattípusokat. Pl: a dátumot ne stringként tároljuk!
- Kerüljük a NULL értéket, ahol csak lehet és állítsuk a mezőket NOT NULL -ra. Kerüljük a használatát még ott is, ahol lehetséges NULL érték.
Inkább tároljunk egy nulla értéket vagy egy üres stringet, mint NULL értéket. Ennek az az oka, hogy a mysql a NULL érték tárolásához több helyre van szüksége. Ha indexeket is szeretnénk létrehozni, akkor plussz 1 bytra is szüksége van az információ eltárolásáshoz. Az első lépésben el kell döntenünk, hogy milyen típusú adatokat szeretnénk letárolni. A következő lépésben pedig ezt később finomítjuk. Sokféle adattípus van, ami ugyanazt az adatot tárolja le csak eltérő határokat, értelmezési tartományokat használ és különböző méreten tárolja őket. Például a DATIME és TIMESTAMP ugyanazt a féle adatot tárolja. A TIMESTAMP másfélszer több helyet foglal, mert speciális tulajdonságai vannak. Példaként lehetne még említeni a fix hosszúságú karakter (char) és a változó hosszúságú (varchar) típusokat. A felhasználói jelszavak md5 kódolásának ideális típusa lehet a fix hosszúságú karakter típus, mert tudjuk, hogy a tárolt szöveg hossza mindig egyforma. A binary és a varbinary típusok hasonlóak, és csak annyiban különböznek, hogy az értékeket binárisan tárolják. Ennek az előnye nem csak abban rejlik, hogy így a karakterek nem érzékenyek a kis és nagybetűkre, hanem abban is, hogy a különböző hasonlítási műveletek lényegesen gyorsabbak, mint a karakteres összehasonlítások. A felsorolást még lehetne folytatni a többi típusra vonatkoztatva is. A célom nem az volt, hogy részletes leírást nyújtsak az alkalmazásukra mivel erre a legmegfelelőbbek a kézikönyvek és az erre a célra írt termék dokumentációk. Inkább csak a figyelmet kívántam felhívni döntéseink fontosságára a tervezés kezdeti szakaszában.
