Hlavní navigace

Názor k článku SQLdep: Rozjetý český projekt v cloudu analyzuje datové toky od booster - SQLDep není nástroj na záchranu jakékoli aplikace. Myslím...

  • Článek je starý, nové názory již nelze přidávat.
  • 9. 11. 2015 17:13

    booster (neregistrovaný)

    SQLDep není nástroj na záchranu jakékoli aplikace. Myslím že v článku bylo, že to je na analýzu datových toků v datovém skladě. Pro OLTP si to ani neumím moc představit, ale DWH jede celý dávkově, jednotlivé SQL příkazy pracují vždy s celou sadou dat a nikoli s jednoltivými klienty či dealy. S ad-hoc SQL příkazy se u DWH moc nepracuje kromě sandboxů (data labů), ale tam zase nepotřebujete dělat dopadové analýzy.
    Pokud má DWH nějaké GUI, tak maximálně pro monitoring běhu jednotlivých ETL procesů.
    Klíčová informace pro analytiky datového skladu je odkud kam v rámci DWH data tečou - když se na začátku stane změna/chyba, tak chci vědět kam se zpropaguje nebo naopak, když je mi podezřelá nějaká hodnota ve výsledném exportu/reportu, tak kde se pro ni posbíraly data. Neviděl jsem nikde takovou (dopřednou) dokumentaci datového skladu, která by umožnila rekurzivně takovéto analýzy provádět.
    Samozřejmě záleží na tom, jak a v čem máte DWH implementován. Pokud jsou to z 99% databázové set-based SQL příkazy, obalené nějakým frameworkem jako (nejen) v mém případě, tak tento nástroj prostě má popsanou přidanou hodnotu. Pokud kompletní ETL mapping máte v SSIS nebo IBM DataStage nebo Informatice (upřímnou soustrast), tak pro výše popsanou analýzu použijete právě SSIS, IBM DataStage nebo nebo Informatiku. Pokud se jedná o kombinaci obou přístupů, tak SQLDep lze nakrmit i "simulacemi" resp. vygenerovanými SQL příkazy, akorát se v nich pak musí analytik vyznat.
    Výhodu SQLDep vidím v agilním přístupu, že smysluplnou poptávku po nové funkcinoalitě analyzátoru kluci v Praze opravdu celkem flexibilně doplní, což se u kluků z IBM nebo Microsoftu spíš nestane.

Upozorníme vás na články, které by vám neměly uniknout (maximálně 2x týdně).