Keresés

Új hozzászólás Aktív témák

  • válasz martonx #9914 üzenetére

    Valóban, a láthatatlanság problémás lehet, de szerintem amiket felsoroltam, azok elég egyszerű feladatok. Illetve triggernél nálam az egy megkötés, hogy ha ír valami mezőt vagy táblát, akkor ugyanazt alkalmazás oldalról csakis olvasom, sosem írom, különben ki tudja mi lesz.

    Ez alól kivételt képez pl a particionálás. Itt pont az a feature, hogy a PL/SQL logika az alkalmazás elől elrejtse azt, hogy valójában több tábla van. Ez DB logika, az alkalmazásnak erről nem kell tudnia. Hasonló az, amikor pl valamilyen bonyolultabb adatszerkezetet (pl fát) tárolsz DB-ben, ennek szabályait is triggerekkel a legjobb megoldani, hogy az alkalmazás kódja ne bloatolódjon szét.

    Igen, az sokszor előfordul, hogy a trigger ír másik táblába, s az meg újabb triggert süt el. Ezek lehet áttekinthetetlen valaki számára, de ha megfelelően jársz el, akkor nincs meglepi. Fontos az egyszerűség.

    Meg lehet csinálni alkalmazás oldalról is, de úgy bonyolultabb megírni, meg jóval lassabb is lenne. Nálam a triggerek a nagyon egyszerű logikákat tartalmaznak, ami nem IF vagy hozzárendelés az kb mind SQL kérés, egyáltalán nem olyan dolog, mint amit alkalmazásban írnál. Ugyanezt tárolt eljárásra átírni elég furán hangzik, hisz maguk a triggerek is tárolt eljárások, csak automatikusan hívódnak, amikor kell. Mi értelme lenne kézzel hívnom, ha lehet automatikus?

  • sztanozs

    veterán

    válasz martonx #9914 üzenetére

    Triggerekben tényleg nem célszerű (általában) üzleti logikát tartani, de szép tervezésnél nincs direkt query alkalmazás oldalról, hanem SP-kön keresztül van megoldva az adatbázis lekérdezés/manipuláció.

Új hozzászólás Aktív témák

Hirdetés