Egyéb kategória bejegyzései

Megtartottam az első SQL Workshop-om :)

Pár hete, igaz cégen belül, de jó tapasztalás volt. Kérték, hogy érdekes legyen, ne az SQL működésébe menjünk bele, így hát megpróbáltam univerzális (adatbázis kezelőtől független) szabályokat a miértekkel és esettanulmányokat bemutatni, az egyiket itt közzé is tettem. Egyértelműen az esettanulmányok voltak sikeresebbek.

Maga az előadás nem volt profi, viszont hasznos, utólag a tények ezt mutatják. A tervezett hossz 1 óra volt, de a sok kérdés miatt, 2×1 óra lett belőle.

Az előadás után sokat töprengtem, mire helyre állt a fejemben, hogy hogyan lehetne jobbá tenni egy-egy ilyen előadást. Egyelőre ezekre jutottam:

  • Az előadásban felváltva legyenek a pihentetőbb, gyakorlati (érdekes) részek (pl. esettanulmány) és a fárasztóbb, elméleti részek, amik a tudást adják
  • A tanagyag egyszerű, lényegre törő és logikus legyen, gyakorlati példákkal alátámasztva
  • Legyenek vicces részek, mert nevetni mindenki szeret
  • Legyen egy jegyzet, amit megkaphat a hallgató

 

Persze el is lehetne olvasni egy (szakmai) könyvet, hogy milyen is egy jó előadás, de most úgy gondolom, hogy még nem érné meg a befektetett időt 🙂

Itt az év vége, engedjük ki a gőzt

Így év vége tájékán megosztanék néhány vicces esetet.

 

1.) Kivételkezlés alkalmazás oldalon:
Hibaüzenet: “No MSSQL”.
2.) Kódoptimalizálás:
— És most frissítjük a gyorsítótáblát
/*
UPDATE table SET mezők WHERE …
*/
3.) A régi idők szekvenciája:
declare @new_id int = (select max(id) + 1 from tábla)
declare @new_id2 int = @new_id + 1

/Aztán mindkét id ment a táblába, amit párhuzamosan is írhattak./
4.) Állásinterjú:
D: Mi a clustered index?
U: Az a primay key. /Határozottan kijelentve/
D: Mi a különbség a primary key és a clustered index között?

A választ meghagyom “logi sztorinak”, de ha követed a felvételiző gondoldatmenetét, akkor könnyen kitalálod 🙂

5.) Felvételi feladat:
D: Ezek a lekérdezések nem használnak az indexet.
U: Olyan kevés a sor a táblában, hogy nem fognak a lekérdezések indexet használni. /Határozottan kijelentve/
U: Csatolva küldöm az új indexeket a régiek helyett…

6.) Tuning:
U: Vegyünk SSD-t! /A proci volt a szűk keresztmetszet/
7.) Statisztika:
U: Nem jó a stat.
D: Okés, milyen szám kell?
U: Nem, ezt nem így kell csinálni. Itt a logika, ami alapján meg kell írni a queryt.

U: Még mindig nem jó a stat.
D: Oké, milyen szám kell?
U: Nem, ezt nem így kell csinálni. Itt a javított logika, ami alapján meg kell írni a queryt.

U: Még mindig nem jó a stat. Ezt a számot kéne kihozni.

8.) Jogosultságok:
U: Kéne sysadmin jog a szerverre.
D: Jó, de akkor nektek kell adminisztrálni a szervert ezentúl.
U: Persze, nem probléma.

U: Kéne egy linked szerver, tudtok segíteni?

9.) Munka:
U: Ezt és ezt kéne csinálni.
D: Okés. De még mondd meg, hogy mi történik ‘A’ esetre.
U: Elmegyek megkérdezem… Szóval, akkor ‘A’ esetre ez van.
D: Okés. Hmmm, ‘B’ esetre mi a teendő?
U: Úúú, erre nem gondoltunk, de elmegyek megkérdezem… Szóval ‘B’ esetre ezt van.
D: Okés. Őőőő, ‘C’ esetre mi van?
U: Mindjárt visszajövök… Az a helyzet, hogy nektek nem lesz vele feladatotok, mi fogjuk csinálni.

10.) Új oszlop:
U: Bele kellene tenni ebbe a táblába is az oszlopot, mert úgy is *-al kérdezzük le, erőforrás meg nincs mindenhol átírni a kódot.
D: Okés, viszont soha nem szűrhettek rá, mert nem indexelt.
U: Persze, úgy lesz.
/Tanultunk az esetből/

11.) Öngól kérdés a management felé:
D: A jó vagy a gyors fejlesztést akarjátok?

12.) Mindent mi sem tudunk:
U: Mi a szuperkulcs?
D: Mi van?
13.) Tervezés:
U: Nem kell, majd alkalmazás oldalon megoldjuk.
D: Okés. /Kevesebb munka, kevesebb gond./

U: Mégiscsak SQL oldalon kéne megoldani.

14.) Scrum:
U: Hogy szoktátok tervezni a napi munkát?
D: Nem tudjuk tervezni, mert napi szinten 5-10 ad-hoc kérés esik be.
U: Jól van, akkor mostantól nektek is lesz scrum.

15.) Scrum-on:
U: Van valami ami akadályoz a munkában?
D: Semmi.
U: Ne csináljátok már, sosincs semmi, had intézzek nektek valamit.
D: Jó, kéne egy új egérpad.

MSSQL vs MySQL 1.0

Az utóbbi időben rendes kiképzést kaptam MySQL-ből és volt is mit optimalizálni MySQL szervereken, ezért erről is fogok írni a jövőben, első sorban olyan jellegű dolgokról, amit lényeges különbségnek találok a adatbáziskezelők működésében. Most nagy vonalakban írok a tapasztalataimról, később majd részelesebben.

Az optimalizálás során az alábbiakat tapasztaltam:

  1. Negatívumok:
    1. Cross / Outer Apply hiánya
    2. Tábla értékkel visszatérő függvények hiánya
    3. Execution plan szegényes információkat ad egy MS execution planhoz képest
    4. Jó végrehajtási tervvel is voltak lassú query-k, amiket több lekérdezésre kellett bontani
    5. Teljesítmény számlálók hiánya, amik csak adott lekérdezésre vonatkoznak. (pl: hány page-et olvasott fel, volt e lookup a végrehajtás során, stb)
    6. Trace-elés hiánya
    7. Sok mindenben kellett a megszerzett általános SQL ismeretekre támaszkodni, mert egyes helyeken kimérni nem, csak sejteni lehetett, hogy hol kell optimalizálni
  2. Pozitívumok:
    1. Set profiling: rengeteget segített a megoldásokban
    2. Query cache: zseniális találmány
    3. Az MS-hez képest egy nagyon rugalmasan kezelt replikációs megoldás
    4. Before trigger

 

Ami itt is előjött, hogy a jól megtervezett adatbázis struktúra a legfontosabb.

Végezetül: a MySQL egy nagyon jó adatbázis kezelő, megvan a felhasználási területe és oda pont ez való. Működésben sok helyen hasonlít az MS SQL-re, ez elég sokat segített a munka során.