OPENQUERY vs. 4 Part Linked Server Syntax

Ha SQL Server alá belinkelünk bármilyen egyéb szervert ODBC driverrel, akkor általában 2 módszerünk van lekérdezni (3 is lehet, de az most nem érdekes).

1. 4 Part Linked Server Syntax

Ez az, amikor simán megírunk egy queryt, mintha "nálunk" lenne a tábla, így:

2. OpenQuery

Az OpenQuery név talán ismerős lehet, ez az, amikor egy string-ben 'átadjuk' a query-t, aminek az eredményét szeretnénk látni. Így néz ki:

Miben különböznek?

Előszeretettel használják a legtöbben az egyszerűség és a paraméterezhetőség miatt az elsőt, hisz olyan mintha egy sima sql query-t írnánk. Akár tárolt eljárásban is használhatjuk, paraméterezhető, egyszerű a where feltétel megadása, sőt, ha így kreálunk egy view-t, abból meg még egyszerűbb lekérdezni.

Feketeleves

Amikor a "túloldalon" megszaporodnak a sorok, egyre lassabb lesz. Egészen egyszerű az oka, ugyanis az történik, hogy a túloldalról ÁTHOZ minden rekordot az adott táblából, és helyben végzi el a szűrést, ami többmilliós rekordszámnál annyira nem hatékony. Emiatt a VIEW-t sem tudjuk használni ami annyira kényelmesnek tűnik, hiszen amikor belekérdezünk a VIEW-ba, akkor is mindent áthoz, majd abból fog selectálni helyben.

A második eset NAGYON macerás, ha tárolt eljárást akarunk írni és paraméterekkel használni, de nem helyben fut le a lekérdezés. Hanem? A túloldalon, és már csak az eredményhalmaz kerül át az sql szerverhez. Szóval sokkal gyorsabb, de sajnos az OPENQUERY-nek nem lehet csak úgy paramétereket átadni.

Magyarul össze kell matyizni az sql stringet úgy, hogy paraméterektől függően legyen benne a where feltétel megírva. 1 paraméternél még annyira nem gáz, de amikor már van 4-5, és vannak dátumok is, és mindegyik lehet null is, akkor nem 2 perces feladat.

Szóval, 2 ma esti mérési eredmény, SQL Express alá linkelt SQLite adatbázissal, aminek adott táblájában 4.7 millió rekord van:
1. módszer: 
futási idő 405 sec

2. módszer: 
futási idő 1 sec

Nem mindegy...

Everything SQL Server Compact

http://erikej.blogspot.hu/2011/01/comparison-of-sql-server-compact-4-and.html
Táblázat a különböző verziók tudásáról:
Compact 35, Compact 4, SQL Express, SQL Server LocalDB

Interjú kérdések

Szemelvények és gyűjtemények az eddigi évek tapasztalatai alapján:

Alapok, amiket jó tudni:
Sokszor előforduló interjú kérdések

Ezekből néhány megválaszolva , amiket neten szedtem össze hozzá.

SQL 2008 interjú kérdések - válaszok egy elég komoly sql server 2008 interjú kérdés gyűjtemény, TANULÁSRA sem rossz...

DOT NET Interview Questions még az előzőnél is komolyabb és tágabb, nem kifejezetten csak technikai kérdésekkel. Project management kérdések is vannak benne. Az alcíme: Including SQL Server, UML, Architecture, Project Management and General Interview Questions

A fenti linken publikált doksikból felkészülve nagy valószínűséggel sikerrel vehetünk bármilyen akadályt :D

De a JOKER kérdést soha ne felejtsük:
Mi a különbség az osztály és az objektum között? :)

Partícionálás visszaállítása

Csak akkor partícionálj egy MS SQL táblát, ha már nagyon biztos vagy benne, annak ellenére, hogy partícionáláshoz jó előre gondolnod kell a táblánál az indexek és mezők létrehozásánál.

You should also not that if you ever needed to REMOVE partitioning from a particular table it is not as straight forward as just issuing the DROP PARTITION SCHEME / FUNCTION.

For example if you needed to place a copy of the database on a SQL Server Standard Edition instance for development work.

You have to:
1 - DROP all relevant indexes on the Partitioned Table(s)
2 - ADD Primary Keys to table(s) where the indexes were removed in (1) above
3 - Then DROP PARTITION SCHEMA
4 - Then DROP PARTITION FUNCTION
5 - Backup & Restore to Standard Edition instance.

SQL sebesség

MS SQL 2008, partícionálás
Partícionált DB-ben part-os indexet vettünk fel. A rendszer válaszideje elfogadhatatlanul lassú volt (10-30sec) egészen addig, amíg az indexekről (illetve a fő clustered indexről) le nem vettük a partícionálást. A táblán maradt.
Így a sebesség helyre állt, de az adatmennyiség jelentősen nem változott a partíciókon (illetve az index miatt a főpart-on).

Térjünk át Oracle fejlesztésre gyorsan, MSSQL szemmel - 2. rész

2. rész, alapvető különbségek

Tegyük fel, hogy az első részt elolvastuk, és megnéztük a tutorialt, felfedeztük a webes adminisztációt. Biztos találkoztunk néhány furcsasággal.

1. Új adatbázis
MS SQL-ben azt szoktuk meg, hogy ha egy új alkalmazást fejlesztünk, vagy ki akarunk próbálni valamit, akkor erre létrehozunk egy új adatbázist. Management studio-ban a Databases-en jobbklikk, és pillanatok alatt készen van. Itt, oracle-ben kicsit mást jelent az, hogy "új adatbázis", más a fogalom. A webes adminisztrációval tudunk ilyet csinálni, de totál mást jelent. Azt jelenti hogy egy új adatbázis instance-t hozunk létre. Egy új service-ünk is lesz, ami éppúgy sok100 mega memóriát megzabál. Nem ezt szeretnénk.
Ami nekünk kell, az egy új Schema. Ez az első fogalom, amit MSSQL ismeretekkel a legnehezebb megszokni. Úgy működik az egész, hogy egy új USER-t kell létrehoznunk, ami azzal egyenértékű, hogy új SHEMA-t hozunk létre. Tehát egy Schema egy User-hez tartozik. Még egyszer, példával. Ha van egy raktár programunk, meg egy webshop-unk, akkor MSSQL-ben létrehozunk egy WMS adatbázist, meg egy EShop adatbázist. És ehhez adogatunk hozzá SQL usereket, adunk nekik jogosultságot, vagy domain usereket használunk, és nekik adunk jogokat. Na, itt, oracle-ben ez nem így van, felejtsük is el ilyen SQL-es emlékeinket kicsit. Itt létrehozunk egy WMS usert, schema-t, és egy EShop usert, schema-t. Ha fejlesztői szemmel nézzük, akkor semmi extra nincsen benne, ha majd az SQL developert használjuk, nagyjából hasonlóan kezeljük mind a kettőt. Kapcsolódunk a szerverhez egy connection-el (aminek a usere pl WMS), és akkor lényegében csak azokat a táblákat/eljárásokat stb. fogjuk látni, amelyek abban a sémában vannak. Pontosabban más séma objektumait is láthatjuk, ha van hozzá jogunk, pl ha SYS userrel csattanunk neki a servernek, mindent látunk! Ez a dolog tehát ne nagyon zavarjon össze minket, nem kell túlspirázni, ez így van és kész. Azt, hogy ennek a hátterében mi van, egyelőre nem kell tudnunk, kezdetnek elég ha megszokjuk.

2. Típusok (Int, Bit, Binary, VarChar)
Int:
Ha MSSQL-ben egy táblát létrehoztunk, akkor az esetek nagy többségében az első mező amit felvettünk az egy Id, ami INT. Na, hát itt olyan sincs. Ugyan némely fejlesztő eszközben ezt ki lehet választani mint opció, nem jelent semmit, ha utána megnézzük a táblánkat kiscriptelve, látjuk hogy NUMBER lett az Id. Ez egy kicsit zavaros, mert ha decimal-t akarunk tárolni, akkor az is NUMBER, a hosszával lehet variálni. Ott lesz ez majd érdekes, ha az ODP .NET providert használjuk .NET kódból, úgy kell majd, hogy ha int-et várunk, akkor az OracleDBType.Int32, ha decimal-t akkor az OracleDBType.Decimal, a tárolt eljárásban meg mindkettő NUMBER. Erről egyelőre elég most ennyi.
Bit:
Az is furcsa lehet, hogy nincs Bit típus. Nincs Boolean. Egyik sincs. Tehát ha True - False értékeket akarunk használni, akkor arra is NUMBER-t javasolnak, amiben 0 meg 1 lesz...
Binary:
Ilyen típust sem találunk. Ha bináris adatot akarunk tárolni, akkor arra a BLOB nevű mezőt kell használnunk, ez a Binary Large Object.
VarChar:
Már nem meglepő, de ilyen sincs. Helyette a VARCHAR2 típust használjuk. Ha hosszú szöveget akarunk tárolni, arra meg a CLOB való, Character Large Object. Arra kell vigyázni a VARCHAR2-nél, hogy amikor a mezőnek megadjuk hogy milyen típusú legyen, és a hosszát is beállítjuk, akkor az alapból nem a karaktert jelenti, hanem hogy BYTE-ban mekkora lehet max. Tehát ki kell választani azt is, hogy CHAR, és így a hossza karakterben értendő. A típusokról itt egy nagyon jó összefoglaló táblázat, érdemes elolvasni, mi milyen hosszú, mi mit tud. Ha MSSQL szemmel akarjuk nézni, készítettem egy megfeleltető táblázatot. Ha valaki hibát talál benne, írja meg kommentben.

3. Autogenerated Identity
Ha egy Unique Id-t akarunk létrehozni, amivel nem akarunk különösebben törődni, azt akarjuk hogy auto-generated legyen, nem triviális Oracle-ben annyira, mint MSSQL-ben. Utóbbiban megadjuk a mező definiálásakor, hogy auto-generated legyen, és ennyi. Oracle-ben nincs ilyen. Ott ún. Szekvenciát kell erre használni. Külön létre kell hozni egy szekvenciát, ami kezeli a mezőben levő NUMBER folyamatos növekedését. Létrehozás, használat. Lehet könnyíteni a használatát, BEFORE Insert Triggert létrehozni, és akkor tényleg nem is kell vele foglalkozni, csak úgy nehezebb az új Id-t visszaadni paraméterként.

4. Szintaxis
Jónéhány eltérés van a szintaxisban is. Mivel ez sok, néhány link, ahol olvashatunk ezekről, később visszatérünk rá.
http://it.toolbox.com/blogs/oracle-guide/what-is-the-difference-between-oracle-sql-and-plsql-9602

http://jopinblog.wordpress.com/2007/04/24/oracle-plsql-equivalents-for-ms-sql-server-t-sql-constructs/

Megjegyzés:
Foly köv., SQL Developer használattal

Térjünk át Oracle fejlesztésre gyorsan, MSSQL szemmel - 1. rész

1. rész, telepítés, ismerkedés

Eme blogbejegyzés azoknak szól, akiknek van már tapasztalata MSSQL fejlesztésben, és ismeretlenül, újoncként egyszer csak bele kell csöppennie az Oracle fejlesztés rejtelmeibe.
Megpróbálom pár bekezdésben összefoglalni, hogy melyek azok a tulajdonságok, amelyeket másképp szoktunk meg MSSQL fejlesztés során, és sokan meglepő arccal (én is köztük voltam) vesznek tudomásul. De no para, nincs nagy vész, idő kérdése és mindent meg lehet szokni, kicsit más szemmel kell nézni.

Ami kellene nekünk, hogy próbálgatni, fejlesztgetni tudjunk, ahhoz egy adatbázis szervert kell letölteni. Ha csatlakozni akarunk a szerverre, akkor mindenféle Client Tool-okat is fel kell tenni, tehát ilyen is kell, és kell egy eszköz, amivel fejleszteni tudunk.
Tehát egy adatbázis szervert kell leszednünk. Lassan 2 éve hogy kijött a 11G, de én próbálgatásnak simán a 10G-t ajánlom, mint release, nincs 300 mega, és elkezdeni teljesen jó. Az Express Edition-t le tudjuk tölteni innen: Oracle Database 10g Release 2 (10.2.0.1). Előtte regisztrálni kell, kicsit macera de hát ez van... Ha letöltöttük, akkor a csomag tartalmazza a client eszközöket is, telepítési útmutató róla itt. Ugyan azt írják, hogy "easy to install", nekem volt már rá példa hogy napokat szívtam, mire normálisan működésre bírtam, és használni tudtam. Amikor először csináltam, egy hétig szívtam (tűzfallal, portokkal, adminisztrációjával, de ez majd másik blogbejegyzés) mire egy tárolt eljárást tudtam hívni. Van akinek ez 3 óra alatt sikerült, nem szétkonfigolt XP-re kell feltenni :).


Szóval ha leszedtük, feltelepítettük az útmutató alapján, akkor ha minden igaz van egy Oracle server instance-unk a gépünkön, és ha jól csináltuk akkor a client cuccok is fent vannak. Ezek majd a szerverhez való csatlakozáshoz kellenek. A telepítőben van egy tool, aminek a neve Oracle SQL Developer. Ez egy ingyenes fejlesztő eszköz. Én nagyon sokat szívtam vele 2-3 éve, fapados volt és bugos. Azért, mert mindössze 4 fejlesztő barkácsolta. Azóta sokminden változott, a csomagban nem tudom melyik verzió van, érdemes a legutóbbit letölteni. Kipróbáltam, hatalmas a különbség (van intellisene, nem fagy, svn beépítve stb), jó lett.


Olyan verziót töltsünk le, amiben van JDK, a letöltő oldalon részletezve van hogy melyikben mi van. Azt is elmondom miért. Ezt az alkalmazást JAVA-ban írják, ugye pont a platform függetlenség miatt, mert ugyan az elején nem mondtam, de egy nagyon fontos dolog: maga az oracle egy platform független alkalmazás, és a hozzá való SQL Developer is. Tehát LINUX-on is fut, ezt az egyik alapvető különbségnek vehetjük (mármint az MS SQL-hez viszonyítva). Térjünk vissza oda, hogy miért olyan kell, amiben van JDK. Azért, mert ha a gépünkön más JVM van fent, akkor könnyen "fagyos" lesz a hangulatunk amikor alkalmanként érthetetlen módon meghal. Az a biztos ami hozzá való. Ezt nem nagyon kell telepíteni, csak kizippelni valahova és elindítani az exe-t.

Mielőtt az SQL developerrel foglalkoznánk, pár szó az alap admin eszközökről. A telepítés után rendelkezésünkre áll egy weboldal a local gépünkön, amin keresztül sok jóságot csinálhatunk. Kezdetnek nézzük meg ez a getting started guide-ot. Ha belépünk pl a SYS userrel (aminek a jelszavát telepítéskor adtunk meg), akkor ilyesmit kell látnunk.

Kattintgassunk, nézzük meg milyen lehetőségeink vannak. Ha ezzel megvagyunk, és kíváncsiak vagyunk hogyan hozzunk létre usereket, táblákat stb, akkor ezt a jó kis tutorial-t átböngészhetjük. Nézzük, emésszük, használjuk a webes eszközt kicsit, de ne vigyük túlzásba mert majd az SQL Developer lesz az, amivel ugyanezeket megcsinálhatjuk. Pöppet emészteni kell. Ha úgy érezzük hogy tisztult, akkor lépjünk tovább a 2. fejezetre, ott a szembetűnő különbségeket, számunkra "újdonságokat" taglaljuk.