-
Fototrend
Új hozzászólás Aktív témák
-
#9929
lezso6
HÁZIGAZDA
fordfairlane
#9928
válasz
fordfairlane
#9928
üzenetére
Ha már OOP, az ORDBMS mond valamit?
-
#9925
lezso6
HÁZIGAZDA
fordfairlane
#9922
válasz
fordfairlane
#9922
üzenetére
A csak tárolt eljárással való API-s megoldás nem jó, mert közvetlenül a tábla adatait szeretnéd piszkálni, akkor borul az egész. Triggerekkel maga az adatbázis önmagában is megáll, nem kell tudni semmilyen API-t, hogy jól működjön, mert elrejti a piszkos részleteket, it just works.
Na mindegy, én is befejezem, mert semmilyen előrelépést nem látok egymás álláspontjának megértésében. Valószínűleg azért, mert én az alkalmazás helyett a DB irányából közelítem meg a problémát, s ez a kettő gyökeresen más szemlélet.
(#9924) fordfairlane: Async trigger? Szerintem ez nagyon megkavarná a dolgokat. Mi lenne akkor a tranzakcióval? Tényleg tök más szemmel közelíted meg a dolgot.
-
De az ilyen tapasztalat az invalid argument, lásd a kacsa és a víz esete. A triggerek ellen szól persze rengeteg érv, de sok másik meg mellettük van. Tudni kell, hogy mire való a trigger, s arra használni, ésszel, ennyi a követelmény.
Azért írtam, hogy "szerintem" meg "nem kell foglalkoznia", nem pedig azt, hogy "ne foglalkozzon".
Mindenki úgy írja meg, ahogy tudja, de azt ne mondja nekem senki, hogy a triggert nem szabad használni. -
válasz
martonx
#9917
üzenetére
Mielőtt egy friss programozó hozzányúl a kódhoz, megnézi, hogy épül fel az adatbázis, az rögtön látja, hogy hoppá, vannak triggerek, s máris ugyanott van, mint a tárolt eljárással. Na meg van egy olyan varázslatos dolog, hogy dokumentáció.
Attól még, hogy neked rengeteg rossz tapasztalatod van valamivel kapcsolatban, nem biztos, hogy az az ördögtől való. Pl rengeteg PHP-ban írt "műalkotás" létezik, de attól még nem lesz a nyelv szemét. Ha a kacsa nem tud úszni, nem a víz a hülye. Persze ha az ember bizonytalan, akkor értelemszerűen inkább ne csinálja, nehogy az legyen az eredmény, hogy valami triggerben van, más meg alkalmazás szinten, tök random, rendszer nélkül.
Az 1-2 sorral több PHP tök jó lenne, de sajnos nem igaz. Ha tegyük fel most le kéne cserélnem a triggereket PHP kódra, akkor pl egy új hsz felvitelénél egy sima INSERT mellett még ezeket kéne megcsinálnia a PHP kódnak:
- téma hsz-számának és utolsó hsz ID-jének frissítése
- téma utolsó hozzászólójának frissítése
- keresőindex frissítése
- particionálás kezelése
- a hozzászóló itt szóltam hozzá listájának frissítése
- a hozzászóló hsz-számának növelése (fórumtól függ, hogy milyen típusú)
- a hozzászóló rangjának léptetése, ha olyan van
- stb.Ha ezek bármelyike nincs, akkor borul a konzisztencia, ezért véleményem szerint az adatbázisban a helyük. Az alkalmazás feladata szerintem az, hogy validációt elvégezze a bemenő adatokon, s azokat az adatbázisnak megfelelő formába hozza és felvigye oda. Azzal nem kell foglalkoznia, hogy bizonyos származtatott vagy kapcsolódó adatok konzisztenciáját fenntartsa. Ezt persze nem kell elfogadni, csak azt próbálom megértetni, hogy mikor lehet létjogosultsága a triggereknek.
-
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?
-
Ezzel egyetértek. Magukkal triggerekkel nincs baj, az emberekkel van a probléma, akik rosszul használják.
Na, de hogy konkrét példák is legyenek, nálam ilyesmik fordulhatnak elő triggerekben (row-level):
BEFORE TRIGGER:
- automatikus mezők kitöltése (ahol a default nem használható)
- integritás ellenőrzés (ahol a check nem használható)
- tiltott operációkra exception (pl egy hsz időpontja nem módosítható)AFTER TRIGGER:
- cache táblák automatikus kitöltése
- kapcsolódó táblák cache mezőinek kitöltése (pl hszszámláló++)
- megváltozott adat korábbi értékének archiválása másik táblábaPersze valaki nem ért a PL/SQL-hez akkor ne így csinálja, s ezeknél magasabb szintű logikát tényleg nem szabad triggerekbe tenni, mert úgy láthatatlan, s abból csak baj lesz.
-
válasz
martonx
#9907
üzenetére
Triggerekkel szerinted mi a gond, pl a példám miért nem jó? Before triggerek helyes használatára szerintem jó példa az egyes automatikusan generált mezők kitöltése, melyekhez pl külső táblból lekérés vagy tárolt eljáráshívás szükséges. Ezt lehet persze enélkül is csinálni, de ez szvsz tök olyan dolog, amit a DB-nek érdemes csinálnia.
(#9905) fordfairlane: Értelemszerűen nem szabad túl sok mindent rájuk bízni. A tranzakciókat nem is értem miért kéne idekeverni.
Egy szóval nem mondtam, hogy az egész business logicot tárolt eljárásokkal meg triggerekkel kéne megoldani, ez persze hogy baromság. Csak egy kis részét lehet, hogy érdemes, attól függően, hogy mennyire bonyolult az adatszerkezeted.(#9909) bambano: Ez se ma volt.
De tény, natív replikáció a 9.0 óta van, viszonylag későn a konkurens megoldásokhoz képest. De van. -
Még ha tegyük fel meg is van oldva tökéletesen, sebességben attól még nem lesz nyerő. Egyébként itt van row-level vs statement-level megkülönböztetés? Honnan tudja, hogy mely row-okra kell meghívni a "triggert", stb.? Ez mind overhead. Persze tudom, a hardver olcsóbb, mint a programozó.
Btw, én nem azt mondom, hogy SQL-be kell, hanem csak bizonyos részét az üzleti logikának célszerű a DB-be pakolni, mert jóval hatékonyabb, mindent használjunk arra amire való, ésszel.
-
válasz
akrobet
#9898
üzenetére
De ez akkor a fejlesztés része, ez megint más, ideiglenesen kb abban írod amiben akarod, a kész szoftvernél meg már fix DB lesz, az ami a legjobb a feladatra. Ám lehet inkább alaposan körül kéne járni és megtervezni a DB kérdést, nem pedig rögtön elkezdeni írni ész nélkül, amikor még azt se tudod hogyan lesz.
-
Pl itt ha egy júzer ír / töröl egy hsz-t, akkor a téma és fórum hozzászólásszáma és az utolsó hsz dátumpecsétje frissül, illetve a júzer lehet rangot léphet, stb. Ezt php-ból megírni elég retek meló lenne, és a bonyodalomból adódóan könnyebben előfordulhatnak bugok, viszlát konzisztencia. S ez csak egy egyszerű példa.
-
válasz
akrobet
#9893
üzenetére
Én sose értettem, hogy miért jó az "univerzális" adatbázis nagyobb rendszerek esetén. Ha képlékeny még, hogy milyen DB kell, akkor még talán megértem, de ennyi erővel meg lehet, hogy a C#-ot kell dobni. A SQL -> noSQL váltási kényszer belekalkulálását meg aztán végképp baromságnak tartom, nagyon másra való a kettő. Egy esetleges DB migrációra fel lehet ugyan valamennyire készülni (ha előre tudod, hogy lesz), de az egy worst-case scenario, emiatt eltoszni a kódot butaság.
-
-
Arra jutottam, hogy a programkód gombra kéne bindelni a monospace stílust a szerkesztőbe. Ellenérvek?
-
-
válasz
sztanozs
#9816
üzenetére
Ha írsz hozzá nyelvi modult. Innen lehet puskázni. Ha valami hiányzik és indokoltan szükség lenne rá, akkor beteszem a támogatást hozzá. Jelenleg ezek vannak:
C / C++, Apache, bash, Java, Javascript, JSON, LESS, CSS, nginx, php, python, SQL, XML / HTML, YAML, Arduino, MSP430.
-
Jött egy feature, talán itt lesz a legjobb publikálnom, hogy mások ne játszanak vele, szóval:
#include <stdio>
// Automatikus nyelvfelismerő szintaxiskiemelés
void main()
{
cout << "Hello C++" << endl;
}/*
Nem csak hozzászólásokban, hanem
bárhol lehet használni, ahol van RTIF. (PH!-s BBCode-szerű izé)
*/
(function() {
window.alert("Hello javascript!");
})()#!/bin/bash
# Az eddig használt [ programkód ] gomb csinálja
echo "hello.txt" > /path/to/file
cat /path/to/file<!DOCTYPE html>
<html>
<body>
<h1 class="ultrabig">Hello HTML!<h1>
<!-- Lehet a boxot középre is helyezni -->
</body>
</html>-- Vagy jobbra...
SELECT sentence FROM world WHERE greeting IS TRUE;P1DIR = 0x01;
P1OUT = 0x00;
// Ez pedig a sorkizárt verzió
while(1)
{
P1OUT ^= 0x01;
__delay_cycles(1000000);
}Sőt a
<?php echo "kód"; ?>akár inline a szövegbe is beágyazható, anélkül hogy beavatkozna a tördelésbe és széthullana a szöveg.Illetve a hsz-író ablakra duplakatt, és monospace lesz a betűtípus meg működni fog a TAB is.
Egy szóval nem mondtam, hogy az egész business logicot tárolt eljárásokkal meg triggerekkel kéne megoldani, ez persze hogy baromság. Csak egy kis részét lehet, hogy érdemes, attól függően, hogy mennyire bonyolult az adatszerkezeted.
De tény, natív replikáció a 9.0 óta van, viszonylag későn a konkurens megoldásokhoz képest. De van.
Új hozzászólás Aktív témák
● olvasd el a téma összefoglalót!
- NVIDIA GeForce RTX 4080 /4080S / 4090 (AD103 / 102)
- OFF TOPIC 44 - Te mondd, hogy offtopic, a te hangod mélyebb!
- Bestbuy játékok
- Motorolaj, hajtóműolaj, hűtőfolyadék, adalékok és szűrők topikja
- Bambu Lab 3D nyomtatók
- Lexus, Toyota topik
- Melyik tápegységet vegyem?
- Szemüveges topik
- Audi, Cupra, Seat, Skoda, Volkswagen topik
- Víz- gáz- és fűtésszerelés
- További aktív témák...
- ÁRCSÖKKENTÉS MSI Z77 MPOWER Alaplap eladó
- DJI Air 3 Fly More Combo RC2 drón - NO LIMITS
- AMD Radeon RX 7900 XT 20GB XFX Speedster MERC310 Garanciás!
- Playstation 5 Slim Disc Edition 1TB, újra fémpasztázva, 6 hó garanciával, Bp-i üzletből eladó!
- CANON Objektív ZOOM Lencse EF-S 18-55mm 1:3.5-5.6 IS / 58
- Samsung Galaxy S23 Ultra 256GB, Kártyafüggetlen, 1 Év Garanciával
- HIBÁTLAN iPhone 15 Pro Max 256GB Natural Titanium -1 ÉV GARANCIA -Kártyafüggetlen, MS3591
- 2025.10.02 - Frissített lista - Lenovo LOQ / LEGION Pro , Yoga Pro (RTX 4060 / 4070 / 4080 / 4090)
- Új pc házak! Kèszleten!
- 145 - Lenovo Legion Pro 7 (16IRX9H) - Intel Core i9-14900HX, RTX 4090 (ELKELT)
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest