Fórumok
Van két összetartozó táblám (idegen kulccsal): tömb - cetli
Egy tömb, sok cetli. Mindkettőben van státuszmező.
Hogy lehet olyan triggert létrehozni Postgresben, aminek a hatására "ha az összes cetli státusz ilyen", akkor a tömbben is átállítsa a státuszt adott másikra?
Hozzászólások
Alapban update, insert triggerjeid vannak. Akkor tudsz futtatni psql eljárást is akár, ami kigyűjti neked. Vagy csinálsz egy viewt amire ránéz a trigger és az alapján dönt.
Egy tárolt eljárás ellenőrzi a feltételt és állítja a tömb állapotát. Ezek után a cetlik táblán lévő triggerek meghívják a tároltat. A tárolt futtatható kézzel is ha kell.
A cetli módosításakor/beszúrásakor történjen? akkor cetlin insert trigger, benne select ami megnézi a new.id* alapján releváns cetlik állapotát és opcionálisan(if) update a tömbre.
*Te id-d.
Gyönyörű. Köszönöm.
A kódrészletet szinte egy az egyben tudtam használni. Annyit változtattam csak, hogy ez az update csak egyirányú lehet (azaz soha nem nyílik meg a cetlitömb, ha már bezártuk), úgyhogy pár sort ejtettem (már csak azért is, mert nem csak két státusz van a tömbnél), illetve az id nálam bigint típusú. Nagyon hálás vagyok ezért, egyrészt tanultam vele, másrészt ez így egyszerűbb és bolondbiztosabb, mint programból megoldani.
Egyébként ez egy csak adatbázisban futó alkalmazás? Vagy egy másik kérdésedben láttam a PHP-t, az hívogatja az adatbázist?
Ha valakinek majd meg kell keresni, hogy miért update-elődik valami, ami nincs benne a programba, akkor a triggerekre is kell majd gondolnia, hogy rátaláljon. És telepítéskor is. stb... Eggyel több hely.
A tranzakciókezelés jól működik egy normális adatbázis kezelőben (amilyen a postgres is), az is bolondbiztos. De ízlések és pofonok. :)
Úgy értem programból megoldani a tranzakció kezelés miatt bolondbiztos, egyébként az a triggerhez is kell.
Nem a kérdésre válasz, de mindenképp triggerrel akarod ezt megoldani? Anélkül, hogy ismerném a feladatot: Én a programban, ahol státuszt állítok a cetlire, ott ugyanabban a tranzakcióban update-elném a tömböt is, ha kell. Vagy ha később a programon kívül "kézzel" update-elném a cetliket, akkor sem nagy dolog a megfelelő státuszúra beupdate-elni a tömböt.
Elvi szinten: most egy dolog, hogy két táblát akarsz így vezetni, és esetleg megoldható egy triggerrel, de ha később valami olyan logikát kell megoldani, ahol három táblában van négyféle státusz, és még két dolog számolódik, update-elődik (vagy még bonyolultabbat), akkor már nem biztos, hogy annyira jó ötlet egy trigger.
Igen, jó felvetés, nincs benne igazi megoldás:
- Lehet hogy a tömbök lekérdezésekor a cetlik állapotát "hozzákérdezzük" (EXISTS, ANY, ALL...). Nem lesz a leggyorsabb, lassú lehet ha tömb állapotra szűrni kell. De gyorsan átvezethető rajta egy üzleti logiak módosítás: pl: "akkor legyen nyitott ha a cetlik legalább fele nyitott".
- A teljesítényt tesztelni kell. Általában hiszünk abban hogy a RDBMS gyors. Ha ez nem lenne igaz, akkor biztos hiányzik egy index (LOL). De érdemes side-effect-eket is viszgálni, pl: tömbhöz tartozik átlag 5 cetli, egyszerű az utolsó/max/átlag lekérdezés. Aztán "egyszer csak" pár tömbnek lesz 10e cetlije, ami a megöli a lekérdezést, mert a query optimizer elkezd más stratégiát választani. Ez még problémásabb ha multi-tenant adatbázisban (több cég egyben) agyik cég egyik tömb-je öli meg az _összes_ cég ezirányú lekérdezéseit.
Lehet hogy félreértem amit írtál, akkor bocs. Én nem mondtam, hogy ne legyen mindkét táblában státusz, csak azt, hogy mentéskor az (akár az az egy rutin), ami az egyik táblát update-eli, az update-elheti a másikat is. A logika egy helyen lenne, nem kettő helyen: egy programban valahol, ami az update-et egyébként is hívja, és egy triggerben máshol, amire vagy emlékeznek majd, vagy nem. De lehet hogy jó oka van a triggerre, csak kiváncsi vagyok miért választotta, vagy miért kell.
Bocsánat. Nem is biztos hogy a te kommentedre kellett volna írnom, hanem csak úgy általában.
Szerintem nem fejlesztő a postolo, hanem üzemeltet valamit. Ezért nem trivialis neki ami nekünk az.
De fejlesztő vagyok, és bennem is mocorog még a kérdés, hogy hová is érdemes tenni ezt a logikát. Lehet, hogy megy a yii2-be. Viszont ha mégis az lesz a célszerűbb, immár megvan az adatbázis oldali lehetőség is.