Mysql optimalizáció,sémaválasztás, indexek.

cikkek marketing pályázat tanúsítás adatbank kapcsolat Ajánlatkérés
E-mail:
Jelszó:
Kulcsszó:
Hírek, információk, tanácsok Vállalkozásod fejlesztéséhez!
Neve:
Email:

 Az ISO 9001 és a minőségirányítási alapelvek várható változásai

Az új ISO 9001 szabvány várhatóan 2015-ben jelenik meg a következő menetrend szerint:

2013. június: a CD (Committee Draft: bizottsági tervezet) szavazásra bocsátása,
2014. április: a DIS (Draft International Standard: nemzetközi szabvány tervezete) szavazásra bocsátása,
2015. július: az FDIS (Final Draft International Standard: nemzetközi szabvány végső tervezete) szavazásra bocsátása,
2015. szeptember: a nemzetközi szabvány kiadása (ISO 9001:2015).

Előző Vissza a cikkek listájához Következő

Mysql Optimalizáció a schema helyes megválasztásával

2009-07-07
Szerző: Döbrentei István programozó


Cikk ajánlása Mondja el véleményét Cikk myomtatása

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 sorn 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.

Küldd el ismerősödnek!

Az Ön neve*
Az Ön email címe*
Ismerőse neve*
Ismerőse email címe*
Ellenőrzés*

Deprecated: Assigning the return value of new by reference is deprecated in /var/www/clients/client1/web122/web/templates/consult/tpl.consultBlock.php on line 32
Online tanácsadás

Kérdező: aranyvirag7
Kérdés: Tisztelt Cím ! Egy IX. József Attila lakótelepi társasházban lakom. A nyílászáróim elavultak, szeretném kicseréltetni azokat, de a lakóközösség nem járul hozzá, hogy közösen fogjunk neki. A kérdésem az lenne, hogy egyedül pályázhatok - e nyílászáró cserére .
A Válasz: Itt olvasható


Deprecated: Assigning the return value of new by reference is deprecated in /var/www/clients/client1/web122/web/templates/dictionary/tpl.dictionaryBlock.php on line 32
Szakszótár

vevõ

szervezet , vagy személy, amely vagy aki kap egy terméket PÉLDÁK: Fogyasztó, ügyfél, végsõ felhasználó, kiskereskedõ, kedvezményezett és megrendelõ. MEGJEGYZÉS: Egy vevõ lehet a szervezeten belüli, vagy azon kívüli.