Zdravím kolegy postižené vývojem aplikací komunikujících s databázemi všeho druhu
,
Fakt nevím, nechci se hádat,
Naopak, jsem rád, že přistupuje k těmto záležitostem věcně, od toho je diskusní fórum , aby se diskutovalo, i když nám může někdo oprávněně zatnout tipec, alébrž se tato diskuse netýká přímo Linux Ubuntu... A také je důležité nenechat si nakukat nějaké nesmysly
Nicméně test čehokoliv před query - má-li být spolehlivý - znamená
1. uzamknout všechny dotčené objekty (přinejmenším pro zápis)
2. provést test
3. provést (či neprovést) query v závislosti na výsledku tesu
4. odemknout všechny dotčené objekty
5. neustále na to myslet
6. doufat, že jsem to udělal opravdu všude, kde to bylo nutné.
Fakt nevím, nechci se hádat, ale přesně kvůli tomu, aby se tohle nedělalo v aplikaci, byly snad triggery vynalezeny, ne? A přesně to je důvod, proč mi nevyhovuje MySQL, i když jinak má nesporné klady (minimálně to, že je automaticky k dispozici na 11-ti hostnizích z 10-ti).
Teď jste uhodil hřebíček na hlavičku, pokusím se vyjádřit...
Trigger je mj. možnost na úrovni databáze, generovat události či na ně reagovat. Pokud např. vložím řádek do nějaké db a mám na této insert operaci zavěšen trigger, pak samotné vložení řádku zapřičiní spuštění tohoto triggeru, tedy dalšího následného procesu s definovaným obsahem. Vložení řádku do table tady zapřičiní,
že se vykoná navíc něco dalšího. Obsahem triggeru mohou být operace kontrolující integritu dat tedy body 1 až 6. Proč ne . To v praxi ale znamená, že budete muset pro každou table definovat trigger a fyzicky jej realizovat : připojit se k dané db, dostat se do exclusive mode, trigger definovat či jej i někdy změnit - Vaše aplikace se bude totiž pravděpodobně vyvíjet v čase podle požadavku zákazníka, což povede pravděpodobně k nutnosti změny struktury určité table (či více tables) a tím i k nutnosti změny triggeru. Teď si vynásobte počet triggerů (co table to trigger na kontrolu konzistence dat dané table) počtem databází u zákazníků. .. Budete ztrácet pravděpodobně hodně drahocenného času pracemi okolo maitenance triggerů, který byste mohl věnovat vývoji aplikace...
Pokud kontrolu integrity dat přesunute do aplikace, lapálie výše popsaného typu odpadají.
Samozřejmě i na úrovni db můžete kotrolovat integritu dat a nemusí to být v triggeru.
Zapisujete do sloupců obdařených klauzulemi UNIQUE či DISTINCT znemožňující zápis duplicitních dat. Nic nezamykáte, jen zkontrolujete chybový code vrácený při modifikaci dat.
Pokud nenastala chyba, je vše OK,, jinak nějak zareagujete. Db stroj vše odemkne ať se stala chyba či ne (nebudu tady probírat situaci, kdy se navzájem lockne víc procesů, to můžeme probrat někde u piva...
, to se mně fakt nechce vypisovat, jsem sorry).
Pokud si to vše dáte do nějaké funkce či metody, která bude realizovat body body 1 až 6,
a která bude provádět fyzicky kontrolu integrity dat a DŮSLEDNĚ NEBUDETE volat "raw"
db příkazy pro modifikaci dat (update/ insert) kdekoliv v programu, ale pouze a jedině tyto funkce, tak na to nebudete ani muset myslet. A to nejlepší nakonec, budete to mít vše na jednom místě, v programu , v jediné metodě (pro každou table jednu metodu např.), kterou prostě kdykoliv upravíte, při změně jí odpovídající tabulky. Její volání rozesejete na oněch 1000 míst ve Vaší aplikaci, ale modifikační místo bude jediné. Takže žádná cesta nocí k databázi zákazníka...
(to je mírná nadsázka v mezích zákona...
)
priznam sa, ze postgre nepouzivam, venujem sa inym databazovym rieseniam, ale dost by ma zaujimalo, v com su triggery v postgre lepsie ako tie v MySQL.
Mne osobne v MySQL chybaju uz len 2 veci. Check constrainty a moznost cez string spustit command, ktory vytvori objekt (proceduru, funkciu), zatial sa daju cez string spustit len bezne prikazy.
Abych pravdu řekl, jestli jsou triggery v PostgreSql lepší než v MySQL, nevím, to jsem nestudoval.
Pokud tady takové srovnání z mých příspěvků zaznívá, tak se omlouvám, neměl jsem je na mysli.
Pokud s tím máte ale někdo zkušenost, tak to sem mrskněte, rád se poučím...
Téma: PHP a PostgreSQL (Přečteno 4258 krát)
