Triggerek, tárolt eljárások és függvények alkalmazása MySQL-ben

Könyv, Kiadvány

Megjelent Jenei Imre "Triggerek, tárolt eljárások és függvények alkalmazása MySQL-ben" című könyve. A tartalomból:

  • Előszó
  • 1. A MySQL telepítése
  • 2. A MySQL adatbáziskezelő elméleti alapjai
  • 3. Sportolók adatait nyilvántartó adatbázis elkészítése
  • 4. Delphi alkalmazások készítése
  • 5. Webalkalmazások készítése
  • 6. C# alkalmazások készítése

A könyv karácsonyig 10% kedvezménnyel és ingyenes postázással kapható az Ad Librum online boltjában. Egy fejezet letölthető a az említett weboldalról.

--

Továbbra is kapható Az Ubuntu világa című könyvünk, karácsonyig ingyenes postázással és 20% kedvezménnyel.

( f0xhu v | 2008. 11. 30., v – 18:50 )

Óriás TéHáIksz!!! :) Pont most van szükségem ilyesmikre.

--
A gyors gondolat többet ér, mint a gyors mozdulat.

( bigwig | 2008. 11. 30., v – 18:57 )

Beleolvastam, és vannak dolgok, amik megijesztenek:

- a példaadatbázisban angol nyelvű sémát használ, ahol az öttusázó 'racer', a nem (férfi/nő) pedig 'generic'
- explicit módon LATIN2 az adatbázis kódlapja
- nem használ foreign keyt
- nem használ constrainteket, inkább triggerrel 0-ba állítja a hibás mezők értékeit
- nem használ viewkat számított mezőhöz, inkább háromszor leírja ugyanazt a képletet egy tárolt eljáráson belül

Ez a könyv 2008-ban jelent meg Magyarországon. Vannak emberek, akik ebből tanulnak bele az adatbáziskezelésbe. Én személy szerint ilyenkor elszomorodom.

http://dev.mysql.com/doc/refman/5.0/en/ansi-diff-foreign-keys.html

Csak kiváncsi vagyok mi az a later stage... :P

Innen a dátum érdekes: http://www.postgresql.org/docs/7.4/static/release-7-4.html
Érzésem szerint már korábban is tudta.

Hopp: http://www.postgresql.org/docs/7.4/static/ddl-constraints.html

Lehet, hogy a pgsql mögött "kicsi" a juzerbázis, viszont még nemnagyon futottam bele olyan viccekbe, mint MySQL-el. Egy konkrét van most előttem, bár emiatt a volt kollégám akarta őket felgyújtani, kellett egy riport és adott mező időit kellett összesíteni. Ezen picit elbukott, mert akármit csinált néhány órás lett a végeredmény és érdekes módon mindíg ugyanannyi, akárhány mező volt benne. Lehet hogy már azóta javították, de nemnagyon követtem.

Nagyon jól használható a pgsql, nagyon szépen működik (nekem eddig legalábbis, biztos van ellenpélda) és jó a doksija is. Az tény hogy nem vagyok database expert (nem is leszek, nincsenek ilyen ambicióim), de pl. a mysql után felüdülés vele dolgozni. Az is igaz, hogy érdemes olvasni a doksit, előtte pedig az elmélettel picit foglalkozni.

szerintem a legtobb esetben arrol van szo hogy milyen celra milyen celeszkozt. Nem arrol van szo hogy most valamihez ez tudja a masik meg nem, lehet hogy a pg is tudja amire szukseg van (mivel ugye altalanosabban tobbet tud sql fronton felmutatni, szoval valoszinu) de "agyuval verebre". Arrol nem is szolva hogy mysql viszont altalanosan gyorsabb a pgnel. En valahol ott kiakadtam anno pgre egyszer mikor egy insert into egy egyszeru tablaba 1.5 masodpercig tartott

Először:
Gajdos Sándor: Adatbázisok

Utána:
Adatbáziskezelőtől függ, MySQL esetén leginkább:
http://dev.mysql.com/doc/refman/5.0/en/
Triggerekről például:
http://dev.mysql.com/doc/refman/5.0/en/trigger-syntax.html

Rosszindulat nélkül szeretném megjegyezni, hogy épp a fenti, triggerekről szóló oldal tartalmazza a Jenei-könyv 38. oldalán szerepeltetett példa kísértetiesen hasonló mását, azzal a különbséggel, hogy ott nem egy constraint _helyett_ szerepel.

Hehe! :) Ebből a könyvből pótzh-zom holnapután. Szerintem jó elméleti alap, pl. a normálformák tárgyalása nagyon hasznos. Viszont sok helyen elég tömör és bekattan az agyam az egymást követő temérdek definíciótól. Én még ajánlanám mellette ezt. Ez olvasmányosabb, kitér sok mellékes szempontra, szerintem nagyon jól meg lehet érteni belőle mindent.

Te constraint alatt most kulso kulcsot ertesz, vagy CHECK CONSTRAINT DDL-elemet? Ugyanis tudomasom szerint CHECK CONSTRAINT semmilyen tablatipusban nem tamogatott MySQL alatt. Kulso kulcs van InnoDB-vel, de ez elegge alap dolog.
Van amikor a CHECK CONSTRAINT jol tud jonni, peldaul amikor a DB-ben is validalni akarod a beszuando adatot, nem csak uzleti logika oldalon (foleg, ha tobb kliens tobb logika megvalositassal kapcsolodik ugyanahhoz a DB-hez)

Az utobbi szivbetegeknek es gyenge idegrendszerrel rendelkezoknek nem ajanlott. Telepitese fokozott hajhullast es a hajszalak elszintelenedeset okozhatja. Az Oracle telepito CD egy alcazott, kozbiztonsagra kulonosen veszelyes eszkoz.
Szoval esszel..

--
I don't always dress in a T-shirt and jeans. Sometimes people give me awards, and I dress like a penguin instead. - Linus Torvalds

-1 a constraintekre és elnézést mindenkitől. Mint kiderült:

"The CHECK clause is parsed but ignored by all storage engines."
(http://dev.mysql.com/doc/refman/5.0/en/create-table.html)

Ki is próbáltam (MySQL 5.0.32): 


mysql> create table test_table ( test_col int , constraint check_test_col check (test_col between 10 and 50));
Query OK, 0 rows affected (0.01 sec)

mysql> insert into test_table values ( 15 );
Query OK, 1 row affected (0.00 sec)

mysql> insert into test_table values ( 5 );
Query OK, 1 row affected (0.00 sec)

mysql> select * from test_table;
+----------+
| test_col |
+----------+
|       15 |
|        5 |
+----------+
2 rows in set (0.00 sec)

Én ezt nem gondoltam volna (legtöbbször én is PostgreSQL-t használok, ott ez nem probléma). Ezért elnézést mégegyszer, különösen az írótól, aki ennek értelmében teljesen megalapozottan valósította meg a contraintet insert és update trigger formájában (ez viszont így nagyon bizarr...)

A kódlap kérdését ettől függetlenül tartom, a foreign key működik InnoDB-vel (igaz mással nem...), view-t is lehetne használni.

Nyugodalmas jóéjszakát.

igen vagom hogy nem jutottal tovabb az apt get install mysql-nel sql temakorben es h szerinted a php akkor az igazi ha mysql van mogotte meg apacs meg debian de

a mysql toketeles eszkoz addig amig pl. statisztikat akarsz benne tarolni vagy usereket tipikusan egy tablas adatstrukturak ahol a konzisztencia nem kovetelmeny -igaz nem is ismeri az architekt-, tehat pont az olyan cegek mint a youtube(nem az SQL a legkomolyabb problemajuk) mysqlt fog hasznalni mivel tudjak h boven eleg ez a funkcionalitas

aztan van a masik eset amikor telleg adatbazis kell es kulonfele programok fognak beleirogatni tarolt eljarasokat hasznalva, adat integritas ellenorzunk meg esetleg szeretnek olyat hogy isolation level mert epp 1000 process olvassa az adatot amikor beleirnek, meg esetleg joljonne a row level locking akkor igy mysqlel mit kezdek?

maradjunk annyiban hogy ahol penzugyi adatokat tarolnak es napi tobb mint 1M tranzakciot dolgoznak fel ott marad az oracle ahol meg tibike LAMP-ol ott meg a mysql(fizetos licensz vajon mi?) mindentol fuggetlenul kar ezen erelni ujra es ujra

"igaz nem is ismeri az architekt"

Milyen architekt? Ne karomkodj! :)

Btw MySQL is tud isolation level, row level locking-ot, de nem is vitatkozni akartam, csak hozzatenni, hogy ha az Oracle-on mulna, akkor jo sok webes projekt nem jott volna letre.

Nyilvan penzugyi celra azt hasznaljak, na de ott a tobbi se PHP (most persze lehetne ellenpeldat mondani).

loooooooooool.
maradjunk annyiban, hogy nem ertesz hozza.

napi tobb mint 1M tranzakcio? oh jesus, most lekene essen az allam, vagy mi?

ne feledd mar el, hogy nem a prog.hu vagy valamelyik tesco gazdasagos forumba postolsz, hanem olyanra, amit olyan emberek is olvasnak, akik tuljutottak mar egy _picit_ a LAMPon, meg a phpn.

11 tranzakcio/s nem sok.

szerintem a hup sokezer kuzere kozul legalabb 10 uzemeltet ilyet, me included. ja, es epp mysql megy alatta. de bocsanat, majd kidobom, es atterek oraclere, igaz, 4x akkora vas kell hozza, es igaz, _nekem_ nem nyujtana semmivel se tobbet. de akkor4444!44

nem vagyok diplomas mernok, szoval meg csak a kemjeid se jelentettek jol

doksit ugye tudsz olvasni?

MySQL uses table-level locking for MyISAM and MEMORY tables, page-level locking for BDB tables, and row-level locking for InnoDB tables.

ennyit a row level lockingrol.

inkabb kerdezz mi az ami nem megy (mert ugye vannak triggerek is mar 5.0ban), es segitunk, minthogy anyazz ;)

Hat lehet hogy tovabb jutottam az apt-get install mysqlnel, de abbol az egy mondatombol biztos jobban tudod hany queryt irok naponta.
Hogy nem tudtad felmerni mit mondok az csak egy masik: A drupal mysqlen megy a legjobban, a tobbi igy-ugy tamogatott, contrib modulok gyakorlatilag csak mysqlen mennek. Ezt mondtam.

Jónak tényleg jó, ha a fentebb említettektől eltekintünk (check constraint csak dokumentációs szerepet tölt be és hasonlók). Lemerném fogadni, hogy sok esetben még gyorsabb is, mint mondjuk a pgsql. Van, ahol ez szempont lehet, de ez önmagában kevés, ha nem szeretnénk mindent kézzel lekódolni. A spanyolviasz feltalálásának érzem, ha a check constraint-eket triggerből vagy az alkalmazásból kell ellenőrizni. Persze, bizonyos mértékig az sem árt a szoftverből is ellenőrizni, de az adatbázisnak önmagában garantáltan konzisztensnek kellene lennie.

Utoljara ertelmesen, hatha:
A valo vilagban eleg gyakori az un. ok-okozati osszefugges.
Jelen esetben ha sok vilagceg milliard dollaros projectekhez hosszas es alapos requirements analysist kovetoen a mysql-t valasztja, annak ha tetszik ha nem oka van. A konkret okok nyilvan cegenkent valtoznak, de altalanossagban elmondhato, hogy scalability vs. tco tekinteteben baromi versenykepes, ezenkivul nyilvan ezer mas is van, kezdve a nagy es aktiv communityvel, ami miatt kicsi a project slowdown eselye, stb stb...

Reszemrol befejeztem a vitat.

( mulder | 2008. 12. 01., h – 14:40 )

Ismerem mindhármat, használom mindhármat. Mindegyik tetszik és megvan a helye a maga módján. Szerintem.

( dejo v | 2009. 01. 05., h – 18:00 )

Megrendeltem! Vicces egy oldal, az biztos.
Még regisztráció előtt elolvastam, hogy 3 féle módon tudom megkapni a könyvet.
1. elmegyek érte
2. elküldik postán
3. elküldik futárral.

Fizeni is több féle módon tudok:
1. postai utánvéttel
2. a futárnak fizetem (a szállítási díjakról érdeklődjek a futárszolgálatoknál ..???)
3. előre elutalom, akkor a szállítási díj olcsóbb.

Beteszem a könyvet a kosárba. Megyek a pénztárhoz, itt vagy bejelentkezek, vagy most regisztrálok. Regisztráltam.
Kéri a szállítási címet. Mondok jó, de ha postás hozza, akkor haza kell kérnem, délelőtt úgysincs otthon senki, megkapom az értesítést majd este elmegyek érte a postára. Ha meg futár, hozza az a munkahelyre kellene hoznia, hiszen itt tudom átvenni.
Kérem otthonra, majd lesz valami! Kiderült, jól tettem, mert futárral történő szállítást nem is lehet választani.
Fizetés módja. No itt minden van csak előre utalás nincs! A bankkártyás fizetést azt nem vállalom, meg nincs is csak elektronikus kártyám. Paypalt sosem használtam még, de hiszen azt olvastam, hogy van előre utalás is, itt meg még sincs. Ha lehet azért szeretek előre utalni, mert nem kell pénzt kivenni és a szállítás is olcsóbb. Jó a szállítás így is olcsó, mert most ingyen van.
Gondolom, az előre elutalás, meg a futár akkor jöhet szóba, ha megfogadom azt a tanácsot, hogy ha "Ha nagyon gyorsan szeretné megrendelését megkapni, érdeklődjön telefonon vagy emailben."
Én a telefonálással kezdtem, de akivel beszéltem az azt mondta, hogy sokkal egyszerűbb, ha regisztrálok és online rendelek. Szóval szeretnek beszélgetni az ügyféllel, a webes rendelés meg nem igazán átgondolt.

Ma van kedd. Remélem csütörtökre megjön!

Megjött. A postaládába kézbesítve. A csomagban volt az átutalásos számla. Utólag fizethettem ki.

--
не закурится!

( dejo v | 2009. 01. 05., h – 18:01 )

Nekem tudott újat mondani a könyv.
Kár hogy a forráskódokat nem lehet letölteni. A könyv kb. 1/3-ada a kidolgozott példák forráskódja.
--
не закурится!