Archívum
Az aktuális csúcstechnológia 5 év múlva már ócskavas lesz
Az Intel elnöke Magyarországon járt.
És ez még semmi, figyi csak: "…az Intelnél öt generációval előre dolgoznak, és a húsz év múlva megjelenő processzorok kísérleti példányai már most rendelkezésre állnak, Barrett megnyugtatott mindenkit: 2025-ig biztosan tartható a Moore-törvény…"
Döbbenetes szavak ezek. Sose gondoltam volna.
A csúcstechnológia mögött mind inkább inkább üzlet van és ennek rendkívül örülök. Nem kell mást tenniük, mint 2-3 évente leemelni a polcról a már kész szuper-chipek valamelyikét, egy kicsit megmarketingelni, felfújni a dolgot, alátenni a puszipajtás Microsoft aktuális oprendszerét ezáltal örökösen izgalomban tartva az IT- piacot.
Fejlődés fejlesztés nélkül?
http://index.hu/tech/hardver/barrett05032/
A nyílt forráskód iránt rajongók üzleti érzéke
A tekintélyes eWeek magazin jelen cikke szerint a nyílt forráskód iránt rajongó emberekből gyakran igencsak hiányzik az üzleti érzék.
– "…némely nyílt forráskódú fejlesztő technikalilag kiemelkedő egyén, üzletileg azonban
teljesen idióta tud lenni…"
– "Igen, úgy vélem a Firefox és Thunderbird jobb. És akkor mi van? Az üzlet nem arról szól,
hogy most éppen melyik a legjobb program."
Így igaz, ezzekkel a megállapításokkal nem is nagyon bírnék vitába szállni. Mindössze annyit tennék hozzá, hogy nem csak a nyílt forráskód iránt áhítattal viselkedő faszagyerekekre igaz ám ez, hanem minden szűklátókörű, úgynevezett szakmai lózungokat hablatyoló programozókra is. Nagyon utálom ezektől az übermennerektől azt halani, hogy "kizárólag szakmai alapokon kell dönteni…".
Mecsoda baromság! Hölgyeim (vagy Uraim)! A világ nem szakmai, hanem gazdasági, pénzügyi alapokon nyugszik, mert a hatalom megszerzéséhez és megtartásához ezek szükségesek. Ha nincs üzlet, nincs pénz, nincs profit, hatalom meg végképp smafu. Az összes szakmai alapon gondolkodó, szűklátókörű, nyálfröcsögtető, szakmaialapondöntéshozó húzzon el a rákba. Előbb legyen pénz, aztán jöhet a szakma. Uff!
Blabla, unalmas mi? De annak azért örülök, hogy a világ túlfelén is úgy gondolják, ahogy én.
Open-Source Fans Often Miss Business Basics
http://news.yahoo.com/news?tmpl=story&u=/zd/20050329/tc_zd/148614
SQL Teljesítményfokozás-II.
Ebben a cikksorozatban igyekszem hasznos információkat adni azok részére, akik némi érdeklődést tanusítanak az adatbázis-kezelő rendszerek SQL-műveleteinek végrehajtási sebességével kapcsolatban (itt főleg a SELECT-re gondolok).
Az előző rész itt olvasható.
Akkor most következzen valami új.
Az állandó (konstans) értékek behelyettesítésének jelentősége
A tranzitivitás törvényének megfelelően szerint sok esetben alkalmazhatjuk az úgynevezett állandó értékek behelyettesítését. Nézzünk is rá mindjárt néhány példát.
1/a. Példa:
… WHERE column1 < column2
AND column2 = column3
AND column1 = 5
1/b. Példa:
… WHERE 5 < column2
AND column2 = column3
AND column1 = 5
ELŐNY: 2/8
Az 1/b. kifejezést az 1/a. transzformáltjának nevezzük (átalakítottuk úgy, hogy az eredeti értelme nem változott meg). Rögtön látszik, hogy az állandó érték tranzitív behelyettesítése kapcsán a 8 adatbázis-kezelő rendszerből 2 esetén teljesítménynövekedés lépett fel (sajnos nem tudni melyik az a kettő).
Nézzünk egy másik példát.
2/a. Példa:
SELECT *
FROM Table1
WHERE column1 = 5
AND NOT (column3 = 7 OR column1 = column2)
2/b. Példa:
SELECT *
FROM Table1
WHERE column1 = 5
AND column3 <> 7
AND column2 <> 5)
ELŐNY: 5/8
Tehát az átalakított (de ugyanolyan értelmű) utasítás az esetek több, mint felében gyorsabban fut.
Megjegyzés:
– A tranzitivitás törvénye szerint, ha A = B és B = C, akkor A = C.
– Az állandó-behelyettesítés az a folyamat, amikor valamilyen állandó értéket (konstans
értéket) helyettesítünk a kifejezésbe.
– Sajnos előfordulhat, hogy az állandó behelyettesítés nem alkalmazható lebegőpontos
számokra. Erre mindig figyelni kell.
– Emlékeztetőül a "nyolcak bandája": IBM-DB2, Informix, Ingres, InterBase, Microsoft SQL
Server, MySQL, Oracle és Sybase. Jelen vizsgálatok ezeken a rendszereken lettek
végrehajtva.
– Az "ELŐNY" arányhányados azt jelenti, hogy a vizsgált 8 db. adatbázis-kezelőből mennyinél
okozott teljesítménynövekedést a megmódosított SQL utasítás.
Folytatjuk…
A tévedés lehetősége
Ja igen, majd elfelejtettem…
Az itt olvasható tájékoztató, ismeretterjesztő írások többsége a saját tapasztalataimon vagy mások által közölt tényeken alapul. Mindazonáltal nem zárható ki részemről a jószándékú tévedés lehetősége sem, habár igyekszem mindennek NAGYON alaposan utána járni.
A magánvélemény az persze egészen más. Az a sajátom, és akit nem érdekel, hát… ne olvassa.
Mindazonáltal továbbra is fenntartom azt, hogy sajnos nem vagyok elég okos, viszont Cogito ergo sum…
Márciusi könyvajánló
Ebben a hónapban is néhány magyar nyelvű (igaz, hogy már régebben megjelent) könyvvel szeretnék kedves olvasóim elé rukkolni. Természetesen a magukat szakembernek képzelők számára ezek is kötelező olvasmányoknak tekinthetők. Mert, ahogyan Zokszigén javasolta: Olvasni NEM gyíkság!
1.
Gulutzan-Pelzer: SQL teljesítményfokozás (Kiskapu kiadó, 456 oldal)
Ez egy gyakorlati megoldásokat bemutató könyv olyan adatbázissal foglalkozó emberek számára, akik élénken érdeklődnek a téma iránt. A korábbi könyvek vagy csak egy adott rendszerrel foglalkoznak, vagy olyan általános megoldásokat adnak, melyek az életben nehezen használhatók. Ez most más, viszont a megértéséhez feltétel, hogy az olvasó rendelkezzen alapvető adatbázis-kezelési ismeretekkel. Az könyv első fele a programozással foglalkozik: gyors lekérdezések elkészítése, adatbázis építés, indexhasználat, a második fele pedig tárolt eljárásokkal, az ODBC-JDBC lehetőségekkel, zárolásokkal és a költségalapú optimizálással. Néhány gondolatot majd idézni is fogok belőle.
http://pcforum.hu/konyvek/SQL-teljes%C3%ADtm%C3%A9nyfokoz%C3%A1s.htm?bid=293
2.
Joel Celko: SQL felsőfokon (Kiskapu kiadó, 536 oldal)
Az SQL felsőfokon az első olyan könyv, amely haladó SQL módszereket mutat be. A szerző meglehetősen közvetlen nyelven ismerteti az olvasóval a lehető legjobb megoldásokat, a helyes gondolkodásmód elsajátítására helyezve a hangsúlyt. A kissé régies, eljárásközpontú megközelítés helyett inkább a logikai, illetve halmaz alapú elemzést helyezi a középpontba. Celko valóban az SQL legnehezebb területeivel foglalkozik, pl.: az összesítő függvények muködésével, a NULL érték helyes alkalmazásával, vagy azzal, miért és hogyan érdemes ál-tömböket használni. A könyvben többnyire termékfüggetlen megoldási példákat láthatunk.
3.
Joel Celko: SQL fejtörők (Kiskapu kiadó, 184 oldal)
Joel Celko ismét nagyot alkotott, ugyanis a legravaszabb fejtörők kitalálására buzdítja olvasóit, majd különböző megoldási javaslatokat és magyarázatokat tesz a jobb eredmény elérésének érdekében. A szerző az SQL szemszögéből világítja meg az adott problémákat, ezzel segítve a gyakorlott SQL szakértőket a gyakran felmerülő típusfeladatok megoldásában. Sok új módszerre és számos hasznos példaprogramra bukkanhat az, aki elolvassa.
http://kiado.kiskapu.hu/main.php?SHOW_BODY=books&OP=detailed&PROD_ID=5
4.
Martin Gruber: SQL "A" – "Z" (Kiskapu kiadó, 480 oldal)
Ez most nem olyan izgalmas, viszont annál hasznosabb könyvecske, amely tulajdonképpen az SQL-nyelv referenciájaként is szolgálhatna. Tartalma az SQL92 és SQL99 szabványokat alapul véve bemutatja, hogy mely lehetőségek származnak a régi szabványokból, és melyek jelentek meg az újabb szabványokban. Fontos tudni, higy a szerző a szabványról ír, nem pedig egy adott adatbázis-kezelő rendszerről vagy annak SQL nyelvjárásáról.
http://kiado.kiskapu.hu/main.php?SHOW_BODY=books&OP=detailed&PROD_ID=8
Áprilisban majd újabb könyvajánlóval jelentkezem (már meg is vannak a jelöltek)…
Röviden az Oracle 9i, Oracle 10g újdonságairól
Néhány gondolat erejéig tekintsük át a régebbi Oracle9i, de még inkább az új 10g érdekességeit. Ez a lista nem teljes, csak egy igen rövid felsorolás.
Oracle 9i:
– ANSI JOIN (SELECT) szintaktika.
– ANSI CASE (feltétel viszgálat) utasítás.
– Új XML és TIMESTAMP adattípusok.
– Belső, XML adatszerkezetek menedzseléséhez utasítások, függvények.
– SELECT… GROUP BY… MERGE, ROLLUP, CUBE, RANK utasítások, melyek a
csoportosításokhoz, összegzésekhez nyújtanak segítséget.
– Stb.
Oracle 10g:
– Új adattípusok: BINARY_FLOAT, BINARY_DOUBLE, SDO_GEORASTER, SI_STILLIMAGE a
nagyméretű adatok tárolásához (képek, videok).
– SELECT… SPREADSHEET: Multidimenzionális táblázatok készítése.
– FLASHBACK TABLE parancs: Adatbázis-tábla törlés (kukába vele!), ami később
visszavonható égészen a PURGE parancs kiadásáig.
– Reguláris kifejezések elemzése: REGEXPR_REPLACE, REGEXPR_INSTR, REGEXPR_SUBSTR
vagyis mintaillesztés alapján történő szövegkeresés (a WHERE… LIKE-nál jóval összetettebb
lehetőségek).
– Újabb statisztikai függvénynek: CORR, MEDIAN, stb.
– Hash-kivonatok kezelése: ORA_HASH.
– Új feltételes logikai műveletek: IS [NOT] NAN, IS [NOT] INFINITE, IS [NOT] A SET,
IS [NOT] EMPTY, IS [NOT] MEMBER OF, stb.
– Új EVALUATE utasítás: Feltételes kifejezések kiértékelése.
– Új PL/SQL csomagok: UTL_COMPRESS (tömörítő), UTL_MAIL (email küldés,
de egyszerűbben, mint eddig), PLSQL_WARNINGS (képernyős figyelmeztetések).
– Java-kezelés továbbfejlesztése (sebesésgnövelés, kapcsolat-cache, stb).
– XML-kezelés továbbfejlesztése: XML-SQL konverziók végrehajtása.
– SQL*Plus alkalmazás-kiterjesztések.
– Stb.
Oracle 10g’s New Grid Features:
http://www.rittman.net/stories/2003/09/16/oracle10gsNewGridFeatures.html
Szigorúan ellenőrzött… kivételkezelés a Java-ban – Utoljára!
Korábban már írkáltam kicsit erről (lásd a Put About – Szigorúan ellenőrzött… kivételkezelés a Java-ban – Megoldva! cikket)
Most csak azért tértem vissza rá egy szösszenetnyit, mert felfedeztem néhány oldalnyi szakirodalmat a témáról. Így pl. találtam egy hullajó írást, amely a Java-C# elemeit hasonlítja össze lépésről lépésre (nem volt cél, hogy egyiket vagy másikat jobbnak kiáltsuk ki, hiszen az baromság lenne, inkább az ismeretek megszerzésére összpontosítsunk). A doksi elmondja melyik környezetben pontosan mi van, ami a másikban nincs vagy fordítva, akár a kulcsszavak meg viselkedések szintjén is (sok-sok példával illusztrálva). Az író szót ejtett a kivételekről is.
Szóval ebben azt olvastam, hogy a szerzőnek nagyon tetszik a Java kivételkezelése, mert annál
dokumentáció nélkül is kiderülhet, hogy milyen kivételeket dob az osztály vagy a komponens, de…
(mindig van egy "de") a C# tervezői, akik között szerepelt Anders Hejlsberg, a Turbo Pascal és a Delphi tervezője is sajnos ezt nem tarthatták szem előtt. Ennek több oka is volt (lassacskán ugyan, de azért tényleg minden kiderül).
1.
No, tehát akkor a Java-tól eltérően vajon miért nem írja elő a C# a nem kezelt kivételek felsorolását, illetve miért nem kötelezi a programozókat arra, hogy ezeket le is kezeljék?
– Az egyik ok bármilyen furcsa, a C++ nyelv viselkedése.
– A másik ok a nyelvek együttműködése. E szerint köztudott, hogy a .NET akárhány nyelvet
támogathat (vagy fordítva?), amelyek megfelelnek a CTS vagy CLS specifikációknak. Az is
köztudott, hogy, a.NET-ben lehetséges menedzselt C++, Fortran.NET vagy akár
COBOL.NET-ből is leszármaztatni mondjuk egy C# vagy VB.NET forrásban. Az írás szerint
nyelvek közötti együttműködés korlátai miatt nem lehetett ilyen mértékű kivételkezelési
kötelezettséget bevezetni.
– A harmadik ok pedig, ha igaz akkor elég zúzós bír lenni. Képzeljünk el egy kliens/szerver
alapú működési módot (ahol a kliens bármilyen alkalmazás vagy komponens lehet, a szerver
pedig egy szintén bármilyen komponens, aminek a szolgáltatását a kliens távolról igénybe
veszi). Klasszikus felhasználási mód.
A klienst mondjuk mi írtuk, de használunk hozzá egy más cég által gyártott akármilyen
komponenst (legyen pl.: egy Ukrajnában gyártott "fekete doboz"). Most technikailag
képzeljük el, hogy ezer helyen használjuk az ukrán szerver oldali komponenst, amivel a mi
kliens alkalmazásunk/komponensünk valamilyen kapcsolatban áll. Egyszer csak a szerver oldali
komponens ukrán gyártója (mondjuk legyen Aljosa) úgy dönt, hogy módosít vagy javít a
belső működésen, aminek az egyik következménye egy új kivétel dobása (és azt a kivételt ő
nem óhajtja lekezelni), és amelyet valamelyik metódus "throws" kulcsszava után egyébként
megadott. FONTOS: A szerver oldali komponens interfésze nem változik!
A példa az életből vett gyakori eset. Ekkor viszont elképzelhetjük, hogy a Java-féle
megoldásnál a "throws" után felsorolt, de abban a metódusban el nem kapott kivételt a
felhasználónak kliensnek) KÖTELEZŐEN kezelnie kell. Igenám, de a mi kliensünk erről még
semmit se tud. E szerint technikailag előfordulhat az, hogy a kliens régi, a szerver oldali
komponens pedig már az új (az új kivételkezelési követelménnyel együtt). Az egy teljesen
bevált szokás, hogy ha egy komponens interfésze nem módosul, akkor a kliens 100%-ig
kompatibilis maradhat a szerverrel (az Aljosa féle szolgáltató komponenssel) és akár időtlen
időkig, akárhányszor lehet cserélgetni a kliens alatt annak a szerver oldali komponensét
(ember, ezt nem én találtam ám ki!).
Vagyis a Java-féle kivételkezelés további bonyodalmakhoz és problémákhoz vezethet.
Ilyenkor vagy újrafordítjuk az összes klienst és lekezeljük az újonnan megjelent kivételt vagy
pedig továbbra is használjuk a régi komponenst megfosztva magunkat az új komponens
nyújtotta lehetőségektől. Még akár emiatt is döntöhettek úgy a C# tervezők arról, hogy
nem úgy fog működni a kivételkezelés, mint a Java-ban.
– Végül egy utolsó indok, melyszerint a C# tervezőinek meggyőződése volt, hogy a
kivételkezelésnek mindig opcionálisnak kell lennie, azaz nem írhatják elő másnak, hogy azt
kötelezően kezelje le. Ez a döntés felhasználó, kliens joga, amit nem lehet elvenni tőle.
Megjegyzem ez utóbbi filozófiai és nem műszaki kérdés.
2.
De van aki ennél tovább merészkedett a Java kivételkezelési probléma témakörében.
A Java a try-catch-finally blokk "finally" ágán lehetővé teszi, hogy abból break, continue,
vagy return utasításokkal kiugorhassunk egy feltétel nélküli vezérlésátadással. Ezzel felülbíráljuk a "throw" kivétel dobás célját és igen drasztikusan megszakítjuk a kivételkezelés folyamatát. Emiatt a finally nem tudja befejezni a dolgát, és nem lehet eldönteni, hogy a kivételkezelés rendben befejeződött-e. A C# tanulva a Java ezirányú hiányosságából nem engedi meg a "finally" blokkból való kiugrást és a külső blokk felé történő vezérlésátadást. Ezt nagyon bonyolult lenne tovább magyarázni, akit érdekelnek a részletek olvassa el lentebb Howard Gilbertnek, a Yale egyetemen született kimerítő tanulmányát, amely példákkal érzékelteti a kivételkezelési problémákat és azok megoldásait.
Mindazonáltal valahol olvastam (a hivatkozás sajno snincs meg), hogy egy ifjú titán összehasonlító méréseket végzett a C++, Java és C# kódokon. Ebben a kivételek feldolgozási sebességét tekintve a Java (J2SE 1.4) megelőzte a C#-ot (.NET Framework 1.1), másban meg nem.
C# and Java: Comparing Programming Languages (Kirk Radeck):
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncenet/html/c_n_java.asp
Exception Handling in Java and C# (Howard Gilbert):
http://pclt.cis.yale.edu/pclt/exceptions.htm
Gondolatok az EDI körül…
Már nagyon régen felmerült az igény arra, hogy a vállalatok között, valamilyen – szabványos – módon, elektronikus formában lehessen adatot cserélni (két számítógépes program közötti adatcsere). Ennek a feladatnak a megoldására korábban szabvány hiányában csak egyedi módszereket lehetett alkalmazni.
A probléma megoldására jött létre egykor az EDI (Electronic Data Interchange), azaz elektronikus adatcsere formátum. Az ebben lévő formátumokat a nemzetközi ISO szabvány deklarálja. A szabvány már több, mint 13 éve létezik, így a világ nyugati felében régóta és rendszeresen használják.
Ez a szabványos formátum tulajdonképpen egy hagyományosan egyszerű szöveges – TXT fájl. A benne lévő tartalmat (kódokat, karaktereket és pozíciókat) a szabvány pontosan definiálja.
Az EDI-ben pontosan szabályozva vannak az adattartalomra (DATA CONTENTS, azon belül data description, data query, app. dependent data flows, id. of parties), a reprezentációra (REPRESENTATION, azon belül syntax rules, character set, framing), és a transzportra (TRANSPORTATION, azon belül data transmission services, pl.: X.400,TCP/IP-FTP, diskette, magnetic tape adathordozó közegek) vonatkozó előírások.
Az EDI használata (a tartalom és forma kötöttségei miatt) nagy szakértelmet kíván. Azt is mondhatnánk, hogy ez egy összetett, precízen megfogalmazott, de nehézkes, rugalmatlan és költséges rendszer, amelynek menedzseléséshez kevés a hozzáértő ember.
Olvastam valahol, hogy az XML technológiákat támogató informatikusok azt állítják, melyszerint az EDI-vel: "Egy atomerőművet is ugyanúgy kell megrendelni mint egy strandpapucsot…"
A fenti mondat az EDI rugalmatlanságát szerette volna érzékeltetni. Ebből, illetve az új igényekből következően, továbbá az internet rohamosabb elterjedése miatt mára már azt lehet mondani, hogy az XML hamarosan kiszoríthatja az EDI-t. Ez egyben azt is jelenti, hogy a régi, EDI kommunikáción alapuló rendszerek még egy jó ideig létezni fognak, de az elektronikus adatcsere formátuma egyre inkább az XML lesz.
Több, nagyobb magyarországi áruházlánc már elvárja el a beszállítóitól és a megrendelőitől, hogy a rendeléseket EDI formátumban kezeljék.
Példa egy EDI fájl tartalmára (részlet):
"UNB+UNOA:2+5990020010002::+5990010050001::+990608:0700+VEGYIMU15+
:+ORDERS++++’UNH+199910158229+ORDERS:D:96A:UN:EAN008’BGM+220+10158229+9′
DTM+137:19990607:102’DTM+2:19990610:102’RFF+ON:10158229’RFF+VA:
10969289-2-44’NAD+BY+5990020010002::9++VILLAMOS HOLDING KFT.
+BUDAPARK KELETI 3.:PF 219+BUDA™RS++2041’CTA+OC+FD05’NAD+DP+5990020011009:
:9++BUDAORSI ARUHAZ GM10+BUDAPARK KELETI 3.:PF 2198+BUDAORS+PEST
MEGY+2041’CTA+SR+00000000000000005’COM+0036-23-418-030:TE’COM+0036-23-418-040: FX’NAD+SU+5990010050001::9++AKARMI FELDOLGOZO RT.+SZEGEDI UT 18
+BUDAPEST++1103’LIN+1++5997046741415:EN’PIA+1+291213:IN’PIA+1+3005127:
SA’IMD+E++:::500ML SLUSSZ FOLY.MOSATOSZER’QTY+21:640’PRI+AAA
:152.88’PAC+++:::ME001DB’LIN+2++5997046740555:EN’PIA+1+764361
:IN’PIA+1+3005852:SA’IMD+E++:::1000 ML MSZ TAPSZER’QTY+21
:360’PRI+AAA:133.98’PAC+++:::ME001DB’LIN+3++5995000040147…"
Megjegyzés: Már az XML-nek is készül az a nyelvjárása, amely az üzleti, ügyviteli életben, illetve az elektronikus kereskedelemben megszokott folyamatokra specializálódik. Ennek neve: ebXML
További EDI információk:
www.edi-tie.com/edifact/index.htm
www.kgazd.bme.hu
www.nls.fi/ptk/standardisation/1.html
www.nls.fi/ptk/standardisation/2.html
www.unece.org/trade/untdid/welcome.htm
SQL Teljesítményfokozás-I.
Ebben a cikksorozatban igyekszem hasznos információkat adni azok részére, akik némi érdeklődést tanusítanak az adatbázis-kezelő rendszerek SQL-műveleteinek végrehajtási sebességével kapcsolatban (itt főleg a SELECT-re gondolok). Nosza rajta, kezdjük máris egy könnyedebb témával…
A kódok rangsorolása
Az adatbázis-kezelő rendszerek kézikönyvei alapján, teljesítmény szempontjából legjobb keresési feltételek azok, amelyek kevés soron, könnyen végrehajtható összehasonlításokat végeznek.
Lentebb látható lesz a keresési feltételek leggyakoribb típusai, méghozzá a legjobbtól a legelőnytelenebbig. Minden elem mellett egy pontszám található. Minél magasabb a pontszám, annál jobb az adott elem (annál inkább azt kellene használni az SQL – WHERE feltétel kialakításakor, ha… lehet).
1. A keresési feltételekben használható műveletek pontozása
Művelet Pontszám
= 10
> 5
>= 5
< 5
<= 5
LIKE 3
<>, != 0
2. A keresési feltételekben használható tényezők pontozása
Tényező Pontszám
Csak literál 10
Csak oszlop 5
Csak paraméter 5
Többtényezős kifejezés 3
Egész adattípus 2
Egyéb számtípus 1
Ideiglenes adattípus 1
Karakter adattípus 0
NULL 0
Nézzünk rá néhány példát is.
a. Példa: WHERE smallint_column = 12345
– 5 pont jár az egyenlőségjel bal oldalán szereplő egyedüli oszlopért,
– 2 pont jár az egész típusú tényezőért (ez a smallint_column),
– 10 pont jár az egyenlőségjelért, és
– 10 pont a jobb oldalon lévő egyedüli literálért (12345).
Ez összesen: 27 pont.
b. Példa: WHERE char_column >= varchar_column || ‘x’
– 5 pont jár az egyenlőségjel bal oldalán szereplő egyedüli oszlopért,
– 0 pont jár a CHAR típusú tényezőért (ez a char_column),
– 5 pont jár az nagyobb-egyenlős összehasonlításért,
– 3 pont jár a jobb oldalon szereplő többtényezős kifejezésért (varchar_column || ‘x’), és
– 0 pont jár külön a VARCHAR típusú tényezőért is (varchar_column).
Ez összesen: 13 pont.
Természetesen ez a két feltétel a végeredményét tekintve nem egyenértékű. A példa csak azt érzékelteti, hogy ahol lehet, ott célszerű végignézni a kombinációkat meg a pontszámokat, és az adott helyzetnek megfelelően kell dönteni. Elsősorban a rangsorolás elvét és magát a sorrendet kell megjegyezni.
A legtöbb pontot az a feltétel kapja (a leggyorsabb az lesz), amelyik a legkevesebb időt veszi igénybe. Általában attól gyorsabb egy feltétel, ha kevesebb sorral vagy egyszerűbb összehasonlításokkal dolozik.
Folytatjuk…
A “Java-saga” folytatódik, azaz mi idegesít engem?
A Java 1.4-ig fennálló felsorolás megvalósításának módja még a kivételkezelésnél is jócskán érthetetlenebb a számomra. Főleg annak tudatában, hogy ott állt előttük példaként az igazán jó alapot jelentő C++ nyelvi szintaktika.
A felsorolásra írtam egy primitív Java példát:
public class Szinek {
public static const Piros = 1;
public static const Feher = 2;
public static const Zold = 3;
private int m_csak_egy_szin;
// konstruktor
public Szinek (int csak_egy_szin) {
m_csak egy_szin = csak_egy_szin;
}
// értékadás
public void SzinBeallit(int csak_egy_szin) {
m_csak_egy_szin = csak_egy_szin;
}// érték lekérdezés
public int SzinLekerdez() {
return (m_csak_egy_szin);
}
}
És ugyanez C++ , illetve C# nyelveken:
enum Szinek {Piros, Feher, Zold};
Nos, biztos, hogy engem inkább a Java-féle tudna az őrületbe kergetni.
No és persze us ugyanez igaz a "struct"-ra, hiszen ez a Java-ban eléggé körülményes lenne, merthogy ilyen nincs is benne, ezért az enum-hoz hasonlóan sajnos azt is csak class-al lehet megvalósítani. Sebaj, ez legyen a legkevesebb, hiszen a struct valójában majdnem egy class.
Folytassuk még tovább és nézzük meg a metódusok dinamikus paraméterezési lehetőségeit:
Ismét egy ici-pici Java példa:
public class Akarmi {
public static void ParamSzimulacio(int[] tomb) {
// itt valami utasítás jönne…
}
}
int[] tomb = {1,3,7,9};
Akarmi.ParamSzimulacio(tomb);
Ugyanaz a példa C#-ban:
public class Akarmi {
public static void ParamSzimulacio(params int[] lista) {
// itt is valami utasítás jönne…
}
}
Akarmi.ParamSzimulacio(1,3,7,9);
A Java-nál látható egy tömb deklaráció, no és persze mindennel, ami evvel jár. Jó, rendben, ne legyünk kicsinyesek.
Végül valami hasonló, de azért mégsem egészen ugyanaz C/C++ -ban:
void ParamSzimulacio(int p1, char p2=’ ‘, char *p3="Izé", float p4=3.1415f);
int main() {
ParamSzimulacio(1); // mindegyik alapértelmezett paraméter érvényre jut
ParamSzimulacio(3, ‘*’); // a p3 és p4 paraméterek alapértelmezettje működésbe lép
ParamSzimulacio(7, ‘+’, "Bigyó"); // csak a p4 paraméter alapértelmezése játszik be
ParamSzimulacio(9, ‘$’, "Valami", 2.38f); // nincs alapértelmezett paraméter felhasználás
return 0;
}
Nyilván a C++ kicsit (vagy még inkább nagyon) másabb. Rögvest meg is jegyzem, hogy a C++ engem untat egy csöppet, no meg azért valljuk be férfiasan, hogy nem is nagyon értek hozzá (meg úgy általában semmihez sem értek, csak mindenbe beleugatok…)
Végül, de nem utolsó sorban példaként hozom fel a nem túl jelentős operátor túlterhelés -operator overloading – témáját, ami a C++ -ban kiváló, de sajnos a Java-ban megint nincs. Valami hasonlót ugyan össze lehet hegeszteni, vagy egy 3. gyártó általi előfeldolgozóval (preprocessor) megreszelni, de mindezt őrületes munkával (a C#-ban is van a C++ -hoz nagyon hasonló operátor túlterhelés).
No, akkor erről egyelőre ennyit.
A problémám az, hogy a Java-ban a C#-hoz képest néhány dolog csak hosszadalmas munkával és körülményesebben oldható meg. Elég, ha csak az eddigieket idézzük fel. Ez nem hiba, nem is nagy baj, legfeljebb néha kényelmetlen és lassú. A nyelv képes lenne a fejlődésre, de mintha valami visszatartotta volna őket. Csakhogy ez hosszútávon nem jó taktika (mint tudjuk a taktika sokat számit, lásd a Microsoft elhamarkodott Longhorn – Internet Explorer stratégiáját, amit mára már végül felülbíráltak).
Erre bizony a Sun is rájött, és talán most,… a Java SE 5.0-ban (az 1.5 csak egy belső verzió) már felébredt végre és néhány olyan dolgot is megcsinált, amit a C++ és a C# igen régóta megoldott. Ezek egyike az eddig leginkább kellemetlen "enum" kérdés vagy a C#-ban meglévő boxing/unboxing technika. Ennél tovább azonban nem is nagyon merészkedtek.
Comparing C# and Java (Budi Kurniawan):
http://www.ondotnet.com/pub/a/dotnet/2001/06/07/csharp_java.html?page=1
Microsoft Visual Studio 2005 és C# 2.0 áttekintés
A hamarosan megjelenő Visual Studio 2005 (Whidbey) és a C# 2.0 számos újításon esett át. Ezek többsége olyan, hogy az eccerű programozó minden ujját megnyalja, miközben olvassa. Aki Microsoft eszközökkel fejleszt, annak ez kötelező olvasmány.
C# 2.0 újdonságok
– Generikus szerkezetek (Generics)
Az osztályok, struktúrák, interfészek és delegate-ek paraméterezhetők a tárolt
adatok alapján. Vagyis még általánosabb, de típusos osztályok, metódusok
készíthetők. Emiatt ritkábban lesz szükség adatkonverzióra (boxing/unboxing). Ha jól
tudom a C++ már valamilyen formában tartalmazott ilyen lehetőséget. Itt van lehetőség
bizonyos osztály vagy metódusszintű megszorítások definiíciójára is (ez az adatbázis
megszorításokhoz nagyon hasonlít, de azért mégsem ugyanaz).
– Anonymus függvények (Anonymus functions)
Olyan kód szekvenciákat készíthetünk, ahol delegate értékeket vár a rendszer. Ezek
hasonlóak a Lisp lambda függvényeihez. A C# 2.0 támogatja azt is, hogy ezek a függvények
a környező lokális változókat manipulálják. Tulajdonképpen "in-line" függvényeknek is
nevezhetnénk őket. A példák megtekintése nélkül ez nem értelmezhető.
– Iterátorok (Iterator)
Olyan speciális függvények, amik inkrementális számításokat végeznek. Bizonyos típusok
esetén ezek segítségével adhatjuk meg, hogy a "foreach" milyen módon járja be a
megadott elemeket.
– Részleges típusok (Partial Type)
A részleges típusok segítségével az osztályok, struktúrák és interfészek több egységre
bonthatók és az egységeknek nem kötelező egyazon fájlba tartozniuk.
– Nullozható típusok (Nullable types)
Egy tetszőleges alaptípus értékkészletét kibővíti a NULL értékkel. Az így létrejött típuson
mindazok a műveletek végrehajthatók, amik az alaptípuson. Korábban ilyen nem volt.
Ezzel a lehetőséggel pl. igen jól lehet illeszkedni azadatbázis-kezelők hasonló tulajdonságaihoz.
– Kompatibilitás
Annak ellenére, hogy több kulcsszó is keletkezett, 100%-os C# 1.0 komatibilitást ígérnek.
Elismerem, a példakódok tanulmányozása nélkül ezek többsége nehezen érthető.
Visual Studio 2005 újdonságok
– Szövegváltozás-követés (Change Tracking)
A forrásszerkesztő különböző színekkel jelzi, hogy az adott kódsorokon belül, a fájl első
megnyitása óta mely sorok: (a) nem változtak, (b) változtak és elmentődtek, (c) változtak,
de még nem mentődtek el.
– Vizuális osztályszerkesztő (Class Designer)
A Visio-hoz hasonló, beépített, grafikus szerkesztő funkció, amellyel új vagy meglévő
osztályokat, metódusokat, adattagokat, jellemzőket, konstansokat, kapcsolatokat, stb.
"szerelhetünk" össze, azok minden tulajdonságával együtt. A végeredmény a forráskód
manipulációja, de vizuálisan. Ilyen eddig is volt, úgyhogy fogalmam sincs, hogy ebben mi az
újdonság (kívülről ez nem látszik). Ezzel az eszközzel lehetőség nyílik arra is, hogy egy
osztályból egy mozdulattal interfészt készítsünk (extract interface).
– Kód gépelést segítő IntelliSense kiterjesztés (Expansions)
No ebbe bizony számolatlanul szórták bele az új, programozói lehetőségeket. Így pl.: kód
bekeretezés, viselkedés XML-be tárolása, Try/Catch segítő, interfész segítő, kivételek
megjelenítése, stb, stb, stb.
– Azonnali objektum teszt (Object Test Bench)
Egy adott osztály példányosítása (alkalmazás futtatás nélkül), a létrejött objektumon belül a
metódusok meghívása, paraméterek megadása, visszatérési értékek figyelése, stb.
– Forrás átalakítás (Refactoring)
A forráskód automatikus átalakítása, átszervezése, ami nem csak egyszerű szövegcsere, mivel
figyelembe veszi a forrás szintaktikai szabályait, lehetőségeit és korlátait is. Igy pl.: csoportos
átnevezések (előzetes betekintéssel), lokális metódusváltozó metódus-paraméterré történő
előléptetése, interfész beillesztés, stb.
– Kódformázás (Formatting)
A forráskód vizuális kinézetének átalakítása előre magdott szabályok szerint.
– Környezeti beállítások
Színek, betűtípusok beállítási lehetőségeinek kibővítése, saját konfigurációs profilok
létrehozása (többféle fejlesztői környezeti beállítás elmentése/visszatöltése), stb.
– Automatikus helyreállítás (Auto Recovery)
A fejlesztői környezetben bekövetkezett fatális hiba automatikus helyreállítása, ami
a környezet és a források helyreállításával társul (a menet közben automatikusan és
folyamatosan elmentett recovery-infok alapján).
– Hivatkozások keresése (References)
A forrásokban lévő hivatkozások keresése, megjelenítése (pl. egy adott osztály, metódus
mely másikakra hivatkozik, vagy őrá kik hivatkoznak, stb).
– A forrás XML-alapú dokumentálójának kibővítése (#region/#endregion utasítások).
– Intelligens címkék (SmartTags)
A környezet és a forrás tartalmától függően különféle kód-darabkák beillesztése és egyéb
segédfunkciók (pl.: névtér hivatkozás automatikus elhelyezése), stb.
– Szöveg keresés és csere lehetőségeinek a kibővítése.
– Újabb vezérlőelemek bevezetése.
– PKI alapú szerelvények (strongly name assembly) menedzselése, melyet eddig csak egy
parancssoros eszközzel lehetett végrehajtani.
– "Egy kattintásos" telepítés (Click Once Deployment)
A folyamatos, fejlesztői környezet alapján nyilvántartott információk alapján, a (webes vagy
hagyományos) telepítőanyag elkészítése – egy kattintásra.
– XML megjelenítés (XML Visualizer)
Bárhol, bármilyen (akár egy változóban lévő) XML tartalomnak a vizuális, betördelt
megjelenítése.
– Forrás nyomkövetés (debug) lehetőségek kiterjesztése.
– Egységteszt (Code Unit Test)
Beépített tesztelési módszerek, tesztelési folyamatok, azok automatikus paraméterezése,
indítása többféle szempont szerint. Minden folyamat vizuálisan is megtekinthető.
New Features in C# 2.0: Part 1. – 2.
http://www.c-sharpcorner.com/Code/2004/March/NewCSharpFeaturesP1.asp
http://www.c-sharpcorner.com/Code/2004/March/NewCSharpFeaturesP2.asp
Visual Studio 2005
http://www.c-sharpcorner.com/vs2005.asp
Nem sikerült lezárni hitvitát
Korábban már én is említettem ezt (lásd a Put About – Kényszeredett beismerés cikket),
de most végre úgy látszik, hogy másnak is feltűnt.
IT-News:
Sok szakmabeli hitetlenkedve ingatta a fejét annak a hírnek a hallatán, hogy egy windowsos webszerver biztonságosabbnak bizonyult, mint a vele azonos módon feltelepített linuxos program.
A teszteredményt floridai kutatók tették közzé a múlt havi RSA konferencián, mégpedig egy olyan csapat, amelynek tagjai között Windows- és Linux-rajongók egyaránt megtalálhatók voltak.
A vizsgálat egyik célja éppen az volt, hogy pontot tegyenek – ha ez egyáltalán lehetséges – annak a hitvitának a végére, amely arról folyik, hogy melyik operációs rendszer a megbízhatóbb.
"Tényszerű összehasonlítást akartunk" – mondotta Herbert Thompson, az egyik résztvevő, "civilben" a Security Innovation nevű, biztonsági technológiákkal és szolgáltatásokkal foglalkozó cég kutatási és oktatási igazgatója. "Rengeteg spekuláció jelenik meg az interneten, a médiában, szakértői elemzésekben ezzel kapcsolatban, mi igazi, betonbiztos tényeket akartunk látni!" – idézi Thompsont a seattletimes.com.
Az összehasonlításban egy Windows Server 2003 és egy Red Hat Enterprise Server 3 szoftver vett részt. A teszt során azt vizsgálták, hogyan futtatják az adatbázisokat, scriptmotorokat és a webszervereket (a Microsoftét az első esetben, illetve egy nyílt forráskódú Apache-ot a másikban). A mért adatok között szerepelt a jelentett sérülékenységek száma és súlyossága, továbbá a javítófájlok (patch-ek), valamint a kockázatos napok száma. Utóbbi azt az időintervallumot jelöli, amennyi egy sérülékenységi probléma megjelenése és a korrigálására hivatott javítás kibocsátása között eltelik. Ebben az összehasonlításban a windowsos konfigurációnál 30 napot regisztráltak, míg a linuxosnál 71-et.
Richard Ford, a Florida Institute of Technology oktatója, a kutatás egyik résztvevője, és nem mellesleg Linux-hívő, igen meglepőnek minősíti az eredményt. "Amikor először láttam a statisztikát, azt hittem, valami összekeveredett itt, de tévedtem." A két kutató egyetért abban, hogy kísérletük eredménye egyértelmű Windows-fölényt mutat.
Ugyanakkor nem mindenkit győztek meg. A két telepített rendszer ugyanis igencsak hipotetikusnak tekinthető, hiszen mindkettő alapkonfigurációt tartalmazott, ami igen távol áll a való élettől. Sokak szerint ha a Windows sok egyéb képességét élesítették volna, akkor eltűnt volna az említett előnye. Ford úgy reagált erre, hogy olyan rendszereket akartak tesztelni, amelyekkel egy átlagos rendszergazda találkozik, amelyeket nem bonyolít el a végtelenségig a kiegészítő funkciók, köztük a biztonsági intézkedések sokasága.
A kutatás jelentőségét az adja, hogy a Windows, illetve a Linux mellett érvelő szolgáltatók, szállítók, szakemberek között éles vita folyik arról, melyik operációs rendszer használata kerül kevesebbe a vállalatoknak. A Linuxhoz, lévén nyílt forráskódú szoftver, sokkal olcsóbban hozzá lehet jutni, de a Microsoft nem győzi felhívni a figyelmet arra, hogy az ő programjait olcsóbban lehet futtatni és menedzselni. A biztonsággal kapcsolatos kiadások pedig jelentős tételét jelentik ez utóbbi költségfajtának.
Bakker! Savanyú a szőlő mi?
Melyik a biztonságosabb: a Windows vagy a Linux?
http://it.news.hu/rios3_content.php?mod=10&id=11792
Szigorúan ellenőrzött… kivételkezelés a Java-ban – Megoldva!
Azt hiszem megtaláltam a hivatalos indoklást az általam korábban említett Java kivételkezelési furcsaságra (lásd a Put About – Szigorúan ellenőrzött… kivételkezelés a Java-ban cikket).
Röviden: minden kivételt, amely egy metódus láthatósági körében felléphet, kötelezően el kell kapni, vagy pedig a throws kulcsszó után fel kell sorolni.
Ez azért lett így megoldva, mert a tervező szerint elképzelhető olyan eset, hogy a programozó nem akar egyes kivételeket az adott metódusban lekezelni, hanem a metódus közvetlen vagy közvetett hívójára hagyja azt (ez amúgy eléggé gyakori eset lehet).
Vagyis a metódus fejében specifikálni kell az összes ellenőrzött kivételt, amely annak láthatósági körében keletkezhet, de önmaga nem kapja el. Slussz-passz, ennyi.
Csak a throws hatására történhet meg az, hogy ha a metódus a fellépett ellenőrzött kivételt nem kezeli le, akkor a JVM (Java Virtual Machine) a hibát kezelő try-catch blokkot egy hívási szinttel feljebb dobja.
Namármost, hogy megtudtam a hivatalos indoklást, cseppet sem jutottam előbbre, mivel nem érzem ennek a kényszerítésnek az előnyét. Ha nem sorolom fel a throws után, nosza akkor mi a bánat van? Semmi? Vagy hiba? Viszont, ha felsorolom, akkor és csakis akkor passzolja tovább a felsőbb szintre. Nekem úgy tűnik, mintha tök feleslegesen járatná velem a köröket.
A Python, C++ és C# nyelvek kivételkezelésében nem szerepel a throws. Ha lesz egy kis időm, akkor majd ezeknek is utána járok.
Does Java need Checked Exceptions?
http://www.mindview.net/Etc/Discussions/CheckedExceptions
The Java Foundry – Exceptions in Java:
http://radio.weblogs.com/0122027/stories/2003/04/01/JavasCheckedExceptionsWereAMistake.html
Programozási nyelvek megbízhatósági kérdései:
http://www.jataka.hu/rics/diplom/diplom.doc
Mi lesz veled SVG?
Lehet, hogy a "Longhorn" – Avalon (XAML) beköszöntével a régi nagy kedvencemnek, a Scalable Vector Graphics-nek (SVG) is befellegzett? Lehet.
Az mindenesetre elgondolkodtató, hogy az Avalon-féle XAML és a Mozilla-féle XML-based User Interface Language-nek (XUL) sem az SVG-re alapozott egykor. No mindegy, majd elválik. Addig is, amíg még létezik kukkantsunk bele picit ebbe a jó kis SVG témába.
Az SVG egy szabványos, XML-alapú, geometriai, vektorgrafikus adatleíró nyelv.
Az SVG a grafikus objektumok három típusával foglalkozik: vektorgrafikus alakzatok (vonalak, amelyek lehetnek egyenesek, vagy görbék), képek és szövegek. A grafikus objektumok csoportosíthatók, formázhatók (pl.: CSS-el) és átalakíthatók. Az SVG-vel lehet beágyazott transzformációkat, kivágásra szolgáló területmegjelöléseket, szűrő hatásokat, és sablonobjektumokat előállítani. Az SVG-rajzok lehetnek interaktívak és dinamikusak. Az animációk definiálása és indítása történhet deklaratív módon is (pl.: SVG animációs elemek beágyazásával magába az SVG tartalomba), esetleg szkripten keresztül.
Összetett SVG alkalmazások használhatnak kiegészítő szkriptnyelvet is, amely eléri az SVG Doumentum Objektum Modellt (DOM). Ez képes teljes hozzáférést adni minden elemhez és tulajdonsághoz. Az SVG grafikus objektumaihoz eseménykezelők (pl.: OnMouseOver vagy OnClick) is társíthatók, melyek mögött akár szkriptműveletek is állhatnak.
Az SVG nem egy cég terméke, hanem egy nemzetközileg elfogadott és támogatott W3C szabvány. Az SVG-ben az általános szintaktikai szabályok ugyanazok, mint az XML-ben. Ez azt jelenti, hogy a geometriai elemek, alakzatok XML nyelven vannak "megfogalmazva".
Az SVG népszerűsége és a felhasználási területe korábban dinamikusabban növekedett (hogy most mi van, arról nincs megbízható információm). Az SVG-hez már számtalan eszköz és egyéb technológia is kapcsolódik. Mindegyik a nevezett adatok feldolgozását, megjelenítését, manipulálását próbálja elősegíteni.
Egy SVG (XML) dokumentumot sokféle módon lehet feldolgozni, de talán a legismertebb az internet böngésző programba beágyazott megjelenítő (pl.: a Microsoft Internet Explorer az 5.5 verziótól kezdődően képes az SVG adatok kezelésére), azonban önmaga nem tartalmaz SVG adatokat megjelenítő funkciót (nálam a Firefox 1.0 is az Explorert indította el, mivel az volt az .SVG-hez társítva). A geometriai alakzatok megjelenítését Plug-In elemekkel (beépülő modulokkal) lehet megoldani. Ez Internet Explorer esetén egy ActiveX vezérlő objektum (pl.: Adobe SVG Viewer).
SVG példa:
<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.0//EN"
"http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd">
<svg width="300px" height="300px">
<g style="fill:#444">
<path d="M0,0v250h300v-250z"/>
</g>
<g style="stroke:#000; stroke-width:2; fill:#f00; fill-opacity:0.5">
<circle cx="100" cy="100" r="80"/>
</g>
<g style="stroke:#000; stroke-width:2; fill:#00f; fill-opacity:0.5">
<circle cx="200" cy="100" r="80"/>
</g>
<g style="stroke:#000; stroke-width:2; fill:#0f0; fill-opacity:0.5">
<circle cx="150" cy="150" r="80"/>
</g>
</svg>
Hát akkor kéremszépen, ennyire egyszerű ez a dolog.
Kapcsolódó információk:
http://www.w3.org/TR/SVG
http://www.protocol7.com/svg-wiki/default.asp
http://www.dbxgeomatics.com/SVG-Intro.asp
http://www.adobe.com/svg/viewer/install/beta.html
Hatékonyabb SQL lekérdezések készítése
Ebben a mindössze két részes cikksorozatban az adatbázis-kezelőknél használatos SELECT SQL-utasítás esetén alkalmazható trükkökre szeretném felhívni a figyelmet (lesz egy másik sorozat is,a mi az általános SQL-teljesítményfokozásról szól, de erről majd később…).
Hatékonyabb SQL lekérdezések tervezésekor a lekérdezés – SELECT – végrehajtásának mindkét fázisát (végrehajtési terv, végrehajtás) figyelembe kell venni. Egyszerű, de gyakran ismétlődő SQL utasítások is leterhelhetik a az adatbázis-kezelő rendszert, ha azokat állandóan újra kell elemezni (parse). Ugyanakkor azonos adathalmaz lekérdezési ideje a leválogatási mód megválasztásától függően akár nagyságrendi eltéréseket is mutathat.
Az Indexelés
Az adatbázis-kezelőnek alaphelyzetben egy lekérdezés végrehajtásához a vizsgált tábla összes rekordját be kell töltenie és ki kell értékelnie a WHERE feltételek szempontjából (FULL SCAN módszer). Általában a FULL SCAN, azaz "a tábla minden során végég lépegető" módszer jár a létező legnagyobb erőforrásigénnyel, mind számítási kapacitás, mind pedig az adatmozgatás szempontjából.
A keresés nagyságrenddel gyorsítható, ha a vizsgált tábla rekordjai a WHERE feltételek szempontjából legalább részlegesen rendezettek (indexeltek). Ilyenkor már csak az index által leszűkített részhalmazon kell a teljes eltételrendszert kiértékelni (a további példákban egy nem létező hallgatói adatbázis-szerkezet fog a bemutatandó műveletek alapjául szolgálni).
Az Oracle adatbázis-kezelő rendszer pl. kétféle indexelési mechanizmust ismer (legalábbis a 8i verzióig), más meg többet. Mindkét mechanizmus esetén egyszerűen csak meg kell adni, hogy mely tábla mely mezőit kívánjuk indexelni, ettől kezdve az az adatbázis-kezelő az indexelést már a háttérben folyamatosan karbantartja. A létrehozásuk így történik:
– CREATE INDEX X1_Hallgato ON Hallgato (nev);
– CREATE BITMAP INDEX X2_Hallgato ON Hallgato (nem, felvetel_eve);
Az első, egyszerűen csak INDEX-ként emlegetett mechanizmus B-fa (B-Tree) típusú indexstruktúrát hoz létre a tábla rekordjai felett, a kulcsmezők alapján. Tipikusan nagy szelektivitású mezőkre szokásos INDEX-et létrehozni. Ezen mezők sokféle értéket vehetnek fel, egy adott értékhez viszonylag kevés rekord tartozik. Egy ilyen mezőt tartalmazó lekérdezés eredményeképpen vagy szűk rekordhalmazt, vagy egyetlen konkrét rekordot szeretnénk válaszul (tipikusan OLTP rendszerek, mint pl.: SAP, Baan, JDEdwards, Navision, Infosys, stb is).
A BITMAP mechanizmus bittáblát hoz létre a tábla rekordjai felett. Minden rekordhoz pontosan egy sor tartozik a bittáblában, míg a bittáblának annyi oszlopa van, ahány lehetséget értéket felvehetnek a kulcsmezők. Tipikusan kicsi szelektivitású mezők esetén használjuk ezt az indextípust, ahol a mező viszonylag kevés különböző értéket vehet fel, és ahol egy adott értékhez sok mező tartozik. Olyan mezők felett érdemes bitmap jellegű indexelést fenntartani, melyekre gyakran futtatunk aggregátum jellegű – statisztikai – lekérdezést (pl: OLAP rendszerek esetén).
Egy tábla létrehozása után alaphelyzetben semmilyen indexeléssel sem rendelkezik. Kivételt jelent, ha a tábla valamely mezőjén UNIQUE, illetve PRIMARY KEY típusú megszorítást (constraint-et) hozunk létre: a megszorítás ellenőrzéséhez az adatbázis-kezelő a megszorítás nevével megegyező INDEX -et hoz létre (ha nem adtunk külön nevet a megszorításnak, akkor a rendszer valami belső nevet generál számára).
Az indexek létrehozásakor figyelemmel kell lenni arra, hogy az index fenntartása költségekkel is jár: tárolóterületet és adatmódosításkor extra karbantartási munkát igényel. Egy "agyonindexelt" tábla lehet, hogy jó teljesítményt nyújt SELECT műveletekre, de ennek ára van, mert az INSERT-UPDATE-DELETE műveletek viszont nagyon lelassulhatnak.
Az Oracle rendszerben (de máshol is) az adatok leválogatásakor az adatbázis-kezelő OPTIMIZER mechanizmusa (lekérdező-optimalizáló) önállóan választja ki, hogy a tábla feletti melyik indexet használja vagy használja-e őket egyáltalán. Az indexet használó ún.RANGE SCAN leválogatási mechanizmus rekordhalmazt, a UNIQUE SCAN mechanizmus egyetlen rekordot választ ki eredményül. Az indexek létrehozásakor ugyanakkor figyelemmel kell lenni arra, hogy az adatbázis-kezelő egy lekérdezés végrehajtásakor egy táblán csak egy indexet használhat.
Hiába van pl. a példa szerinti hallgatókat tartalmazó táblán index külön a születési helyre és külön a születési időre, egy adott helyen és időben született hallgatókat listázó lekérdezés vagy az adott helyen született, vagy az adott időben született összes hallgatót fogja végignézni. Ha a születési hely és idő gyakran fordul elő együtt lekérdezésekben, akkor érdemes számukra közös indexet csinálni, pl.:
– CREATE INDEX X3_Hallgato ON Hallgato(szuletesi_hely,szuletesi_ido);
Az ehhez hasonló, több mezőt magában foglaló indexeket az OPTIMIZER akkor tudja felhasználni, ha az SQL-WHERE feltételben az index első néhány mezője szerepel. A fenti indexet tehát akkor is használhatja, ha csak születési helyre keresünk, ugyanakkor nem használja, ha csak születési időre keresünk.
Az alábbi általános tanácsok fogalmazhatók meg az indexek megválasztásához:
– Olyan mezőket érdemes INDEX struktúrával ellátni, melyeknek nagy a szelektivitásra,
és amelyekre gyakran hajtunk végre lekérdezést.
– Az indexek megválasztásakor mérlegelni kell a SELECT, illetve az INSERT-UPDATE-DELETE
műveletek költsége között.
– A keresési feltételekben gyakran együtt felmerülő mezőket érdemes együttesen indexelni.
Az együttes indexben a mezők sorrendjét úgy célszerű megválasztani, hogy az önállóan is
gyakran feltételként szereplő mező előre kerüljön.
Megjegyzés:
– A fent elmondottak többsége bármely relációs adatbázis-kezelő rendszerre igaz lehet.
– Az Oracle adatbázis-kezelő rendszer a 10g verziótól inkább a költség alapú
optimlizálást részesíti előnybe a szabály alapúval szemben.
Folytatjuk…
Put About 
Hozzászóláshoz be kell jelentkezni!