- A Föld teraformálásával építene galaktikus birodalmat Elon Musk
- Huawei Watch GT Runner 2 – óra a futóra?
- Ez most a legjobb robotporszívó. Kérdőjel? De nem olcsó. Pont.
- Áprilisban érkezhet a OnePlus Ace 6 Ultra, közben új tabletek is készülnek
- Oppo Pad Mini néven készülhet a gyártó új, kompakt, prémium táblagépe
- Google Pixel topik
- Áprilisban érkezhet a OnePlus Ace 6 Ultra, közben új tabletek is készülnek
- MWC 2026: Bajnoki címre pályázik a Xiaomi Watch 5
- Xiaomi 15T Pro - a téma nincs lezárva
- iPhone topik
- Íme az új Android Auto!
- Redmi Note 13 Pro 5G - nem százas, kétszázas!
- Google Pixel 10a – évismétlés
- Xiaomi 17 - még mindig tart
- OnePlus 15 - van plusz energia
-
Mobilarena

Új hozzászólás Aktív témák
-
martonx
veterán
válasz
fordfairlane
#9903
üzenetére
+1 a triggerek ellen. A tárolt eljárások viszont egy bizonyos DB méret / teljesítmény elvárás felett kikerülhetetlenek. No persze ilyenkor jön be az, hogy X TB-os DB-t az ember már amúgy sem hordozgat, nem migrálgat Oracle-ről MS SQL-re és vissza, vagy pedig rászánja azt a pár ember hónapot a feladatra.
A debugolás persze más kérdés. Egyrészt MS SQL tárolt eljárásait lehet debugolni, másrészt SQL szinten a debugnak sokkal kevesebb értelme van, harmadrészt egy SQL kód azért még mindig egyszerűbb, mint egy komoly C# logika (jó, láttam már 1500 soros tárolt eljárást is, na azt debugolni nem volt kellemes, de azt is a kényszerűség szülte, direkt SQL szinten tartva a logikát is 15 perce futásideje volt egy 96 magos SQL szerveren).
Jellemzően azért könnyen meg lehet találni SQL-ben is, hogy hol ment félre egy where feltétel, vagy egy join.
Új hozzászólás Aktív témák
● olvasd el a téma összefoglalót!
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest



