Legtöbb SQL server úgy épült fel, hogy fogták az SQL specifikációt, beépítették. Aztán ahogy az idő múlt, mindenki szépen kidolgozta a parancsokat és eljárásokat azokra az esetekre, amiket a specifikáció nem fedett le.
Hónap: 2017 március
Triggert heggesztettem
A tigger nem jó, de néha elkerülhetetlen.
Készítettem két triggert (egy insert meg egy update), amikkel egy tábla adatainak változásának tényét írom egy másik táblába. Tehát az történik, hogy egy tábla jegyzi, hogy melyik rekordra történt insert vagy update. Ennyi az egész:
- recordid
- insert/update
Aztán majd egy ütemezett tárolt eljárás feldolgozza ezt a táblát és akkor nyúlok hozzá bővebben az eredeti tábla adataihoz.
Betartottam a saját szabályaimat:
- típusonként csak egy trigger
- tökéletesen hibatűrővé tettem
- csak egy másik táblához nyúltam hozzá belőle
- és oda is csak a minimális adatot írtam
Ma Access-szel foglalkoztam
Nem igazi adatbázis-kezelő, vagy talán mondhatni rá, hogy alap adatbázis-kezelő (Jet/Ace), mindenféle sallanggal megtámogatva (valami RAD tool).
Van olyan, hogy túl sok index?
Hogy ne lenne!
Tegyük tisztába: az indexek a lekérdezések gyorsaságát befolyásolhatják.
Union vagy or?
Sok helyen olvastam már, hogy az or helyett használjunk uniont.
Bár a logikáját értem: az or nem tudja teljesen kihasználni az indexeket, míg a union két (vagy több) része meg igen. De azért álljon meg a fáklyásmenet! Itt is először gondolkozni kell, csak aztán alkalmazni!
Like vagy substring?
Tegnap az volt, hogy a like 'akarmi%' formát használjuk. Ugyanez igaz, ha a substring-gel hasonlítjuk össze.
Like
Tudom, elcsépelt, de ne használjuk a like '%akarmi' formátumot. Meg ebből következően a '%akarmi%' formátumot sem.
Tranzakciós adatok vagy BI adatok?
Ma kikényszerítették belőlem, hogy közvetlenül feldolgozatlan tranzakciós adatokból készítsek BI felhasználásra adatokat.
Trigger, trigger…
Ne használj triggereket soha. Legalábbis sok helyen ezt ajánlják. Én ezen finomítanék: ésszel használj triggereket.
Count, de mit?
count(*)? count(1)? count(PK)?
