- bambano: Bambanő háza tája
- sziku69: Szólánc.
- sziku69: Fűzzük össze a szavakat :)
- Argos: Az vagy, amit megeszel
- Luck Dragon: Asszociációs játék. :)
- sellerbuyer: Milyen laptopot vegyek? Segítek: semmilyet!
- Barthezz2: Cím: Ismeretlen - Chapter 5
- gban: Ingyen kellene, de tegnapra
- Magga: PLEX: multimédia az egész lakásban
- D1Rect: Nagy "hülyétkapokazapróktól" topik
-
LOGOUT
Ú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.
-
-
-
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!
- Xiaomi Mi 8 - így csinálunk csúcsmodellt Mi
- exHWSW - Értünk mindenhez IS
- Autós topik látogatók beszélgetős, offolós topikja
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Autós topik
- Projektor topic
- Synology NAS
- Azonnali VGA-s kérdések órája
- Yettel topik
- iPhone-t használók OFF topikja
- További aktív témák...
- HIBÁTLAN iPhone 13 mini 128GB Blue -1 ÉV GARANCIA - Kártyafüggetlen, MS3362
- ÁRGARANCIA!Épített KomPhone i5 13400F 16/32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
- Honor X6b 128GB, Kártyafüggetlen, 1 Év Garanciával
- ÁRGARANCIA!Épített KomPhone i7 14700KF 32/64GB RAM RTX 5090 32GB GAMER PC termékbeszámítással
- Huawei P20 Lite 64GB, Kártyafüggetlen, 1 Év Garanciával
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest