Egyéb kategória bejegyzései

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.

 

 

Kevesebb feature, kevesebb gond

Nem tudom Ti hogy vagytok vele, én igyekszem minél kevesebb SQL Server feature-t használni, amikor kódot írok. Az ok teljesen egyszerű. Az SQL Server egy hatalmas szoftver, óhatatlan, hogy ne legyen benne bug. Kevesebb feature, kevesebb bug. Olyan ez, mint a legkisebb jogosultság elve, csak a funkciókra vetítve.

Szintén fontosnak tartom, hogy nem csak az új funkciókkal lehet gond. Egy meglévő is “elromolhat”. Volt már rá példa, biztos vagyok benne, hogy még lesz is. Érdemes csak azt használni, amire valóban szükség van.

Amikor business critical adatbázisról van szó, akkor nem mindegy, hogy az áll, rosszul működik vagy jól dolgozik. Én az utóbbit szeretem. Ez jó nekem, jó a cégnek, jó az ügyfeleknek.

Használjuk ki felelősséggel az SQL Server lehetőségeit.