TCZ

Olykor előfordulhat, hogy egy hibás program megduplázza (triplázza, kvadplázza) a rekordokat egy adatbázistáblában. MySQL egyszeregy következik.

Nagyon egyszerűen elkerülhetjük ezt az esetet. A bejegyzés végén persze azt is elárulom, hogyan töröljük ki a felesleget, ha már megtörtént a dolog, ám előbb a megelőzés: azokra a mezőkre, amelyeket együtt csak egyszer akarunk látni (pl. termékazonosító, ár és ár érvényessége) csinálunk egy közös unique indexet.

ALTER TABLE `arak` ADD UNIQUE `egyedi` ( `termekid` , `ar`, `ervenyes` )

Ezzel biztosítottuk, hogy ugyanolyan felállás az adott mezőket tekintve nem fordulhat elő egy újabb rekordban. Ezután csak annyi a dolgunk, hogy eldöntsük, mit tegyünk hasonló rekord beszúrásakor. Ugyebár két lehetőségünk van, a felülírjuk a már létező rekordot az új adatokkal, vagy hagyunk mindent a régiben. A titkos harmadik lehetőség a kivétel generálása.

1. INSERT INTO `arak` SET `termekid`=15, `ar`=990, `ervenyes`=’2009-08-01 0:00:00′ ON DUPLICATE KEY UPDATE `termekid`=15, `ar`=990, `ervenyes`=’2009-08-01 0:00:00′

Mi történik itt? Az “ON DUPLACATE KEY UPDATE” kifejezés annyit csinál, hogy ha már létezik a táblában olyan kulccsal (vagy unique index-szel) rekord, amit be akarunk szúrni, akkor megelőzi a beszúrást, és felülírja a megadott mezők értékét. Esetünkben a frissítéshez minden mezőt felülírunk, ami az INSERT-ben eredetileg szerepelt.

Megjegyzem ennek a módszernek csak akkor van értelme, ha a fenti három mellett vannak még más mezők is a táblában. Például egy megjegyzés mező, vagy egy akciós flag, amit egyáltalán felül tudunk írni. Hiszen ha ilyen nincs, akkor a rekord nem változik. Apropó nem változik…

2. INSERT IGNORE INTO `arak` SET `termekid`=15, `ar`=990, `ervenyes`=’2009-08-01 0:00:00′

Itt az IGNORE kulcsszó hatására a MySQL a beszúrás során fellépő hibákat figyelmeztetésként kezeli, és nem akasztja meg az egész tranzakciót, például. Ezzel a módszerrel tehát azt érhetjük el, hogy a beszúrt rekord ütközés esetén ne íródjon felül, tehát az új rekord beszúrása ne történjen meg, és ne legyen hatással a régire.

3. INSERT INTO `arak` SET `termekid`=15, `ar`=990, `ervenyes`=’2009-08-01 0:00:00′

Ez a harmadik eset, ilyenkor – már létező kulcs esetén – a végrehajtás hibát fog generálni. Ez is hasznos lehet olykor.

Mindhárom módszer nagyon fontos olyan esetekben, amikor például különböző adatbázisokat szinkronizálunk.

Ha viszont már elb*sztuk, és a táblánk tele van mindenféle hasonló rekorddal, amelyekből nekünk csak egy kell per fajta, akkor itt egy kis elsősegély:

CREATE TABLE `uj_arak` AS SELECT * FROM `arak` GROUP BY `termekid` , `ar`, `ervenyes`

Ezzel létrehozunk egy ugyanolyan táblát, mint az eredeti, és beletettük az eredetiből az egyedi rekordokat – legalábbis amelyeknél a termekid, az ar és az ervenyes mező együttesen egyedi. Ez lesz a cseretáblánk.

Nem szabad megfeledkeznünk arról, hogy az indexek ilyenkor nem jönnek át a régi táblábból! Ezeket újra el kell vennünk.

Ha ez megtörtént, akkor már csak a cserét kell végrehajtanunk.

DROP TABLE `arak`;
RENAME TABLE `uj_arak` TO arak;

Ennyi az egész.

… még egyszer ránézni a kreatívra, nehogy nemkívánatos asszociációkat ébresszünk. Vagy csak én vagyok túl mocskos?

http://wop.hp.hu/

Tovább…

Mindössze egy sort írok, hogy megköszönjem a zsűrinek, hogy a Goldenblog IT szekciójának 7. helyére mélónak ítélt. Hatalmas megtiszteltetésnek és elismerésnek veszem. Köszönöm, erre nem is számítottam.

Mindenki hallotta már, jövőre jön a Google OS. Kíváncsian várjuk. Meg is születtek az első szkeptikus posztok ezzel kapcsolatban – egyébként pont emiatt praktikusabb titkolni egy projektet, amíg nincs valami kézzel fogható, megszemlélhető, megszaglászható eredménye.

Mi a fikázás (újabban “fikázódás“) fő mondanivalója? Az, hogy senki nem fog használni egy olyan operációs rendszert, ami képességeit tekintve alulmarad a versenytársaktól, pehelysúlyú, “semmire se jó”. Ezzel pedig egyáltlaán nem értek egyet.

A Google mindig is megelőzte korát. Az egyetlen nagy hibája az lehet a ChromeOS-nek, hogy túl hamar jön. Hogyhogy?

Valamikor az 50-es évek elején az IBM-nél úgy számoltak, hogy a világon összesen évi 5 db számítógépre lehet kereslet. A mai szemmel nevetségesnek tűnő elképzelésnek új értelmet ad a 21. század és a szélessávú internet. Annak, hogy a személyi számítógépek (nem csak PC-k) ilyen mértékű technológiai (és mennyiségi) fejlődésen mentek át az elmúlt évtizedekben, egyetlen oka van. A Földet behálózó számítógépes hálózatok fejletlensége. Úgy sávszélesség mint penetráció tekintetében.

A világ a webbel az élén ma affelé tart, hogy egyre kevesebb desktop alkalmazást használunk. Sok felhasználó egyetlen, saját gépén futtatott szoftvere a böngésző. Ott fut a “gémél”, a Spreadsheets, ott a youtube, a facebook. Rengeteg játék van, és sok olyan webes szolgáltatás, amely kiváltja az asztaliakat. Én például már nem használok konvertáló programokat, kizárólag weben. Ráadásul – ami még szebb – egyre kevesebb kód fut le kliens oldalon. Egyre több olyan webes szolgáltatás létezik, ami intenzíven használja az AJAX technológiát akár olyan feladat elvégzésére, ami kliens oldalon is elvégezhető lenne.

A számítási feladatok szépen áttevődnek a szerverekre. Nemsokára nehéz lesz különbséget tenni a webes illetve az asztali felhasználói élmény között, hiszen a webes GUI-k reagálási ideje nagy mértékben meg fogja közelíteni az desktop alkalmazásokét. Csak a vak nem látja, hogy milyen irányba megyünk. Egy fog érkezni az idő, amikor egy átlagos internetkapcsolat sebessége lehetővé teszi, hogy kifogástalan minőségű képet és hangot stream-elünk a szerverről, és késleltetés nélkül küldünk vissza user inputokat. Mintha csak a saját gépünk képét látnánk. Ha ez megvalósul, akkor a teljes számítási teljesítmény áttevődik az óriási szerverparkokra, melyeken videókat játszhatunk le, 3D-t renderelhetünk, dokumentumokat szerkeszthetünk.

Az egész világ egy nagy terminál kliens és szerver tömeg lesz.

Hogy ez miért szükségszerű? Mert az egész rendszer számtalan előnnyel jár; Takarékos - nem kell drága hardverekre költeni a végfelhasználóknak. Nem pazarol az erőforrásokkal – a szerverek számítási teljesítménye sokkal ügyeseben elosztható, mint egy-egy kliensé. Teljes mobilitást biztosít – ugyanazt a teljesítményt érhetjük el mobilon, mint PC-n, és bármelyik terminálhoz odaülve ugyanazt kaphatjuk. Gyors - ha az éppen bérelt szerver teljesítménye nem kielégítő, kibérelek egy helyet egy gyorsabb kiszolgálón mondjuk egy hétre.

Persze ez egy nagyon utópisztikus, középtávlati vízió, de a folyamat már elindult. Ezt pontosan láthatjuk a hardverpiac megtorpanásán, és az olyan próféták lépésein, mint a Google. Szerintem egy pehelysúlyú operációs rendszer, mellyel könnyedén és biztonságosan érhetjük el a webet, ennek a folyamatnak az előfutára. Szükség van rá? Igen. Sikeres lesz? Valószínűleg.

Az összes félelmem tényleg csak annyi, hogy koraszülött lesz a ChomeOS.