Zkusim si trochu zaspekulovat (na zaklade obdobneho omezeni v eBance):
Mozna, ze omezeni na vyhledavani po trech mesicich je z dobudu vykonnosti. I eBanka neco podobneho zavedla, protoze bylo potreba snizit vykonove naroky na vyhledavani v historiich. V eBance se to da sice zmenit, ale malokdo to dela ( -> vykonove naroky zdaleka nejsou takove jako by v cele historii vyhledaval kazdy).
Bohuzel (prestoze to tak nekdy vypada) ani banky nemaji databaze ktere by zvladly libovolny vykon. Navic je vykon zalozeny na vstupech z webu do jiste miry neplanovatelny. Proto je zrejme prohledavani v historii omezene. Databazim to ulehcuje.
A proc ma jiny typ uctu jina omezeni? Mozna jsou jine ucty vedene v jinem vnitrnim systemu, ktery ma jine moznosti, jiny vykon, atd. atp.
Muze a nemusi to tak byt. Mozna opravdu nejaky manager chtel pridat podminku, aby mel pocit ze je spoluautorem :-)
"i ebanka něco podobného zavedla"??
V ebance je vyhledávání v historii omezeno rozsahem 370 dní, takže pokud chcete posledních 370 dní zadáte parametr -370, pro starší období prostě datum od-do. Pracuji s účty v ebance od roku 1997 a žádné omezení historie jsem nezaznamenala..
Mozna jsem to spatne napsal, omlouvam se. Bylo to mysleno takhle:
V prvnich verzich Internetoveho bankovnictvi Expandia banky to "omezeni" na 370 dni nebylo, prohledavala se cela historie. Az pozdeji tam pridali "filtr" ktery standardne kouka jenom 370 dni dozadu a pokud chcete koukat na pozdejsi veci, musite si vybrat obdobi, nestaci jenom mackat "na dalsi stranku".
Tj. tam kde je dnes napsano "Nespecifikovano (poslednich 370 dni)" drive byvalo jenom "Nespecifikovano"
"Proto je zrejme prohledavani v historii omezene. Databazim to ulehcuje"
Verte tomu, ze je to pouze spatne naprogramovane a uz jsou lini to opravovat.
Argument, ze nemam ten spravny ucet a ze nemam moznost tedy zobrazit "lepsi" historii nebo ja nevim co, je jen slabost banky a osobne bych se rozhledl nekde jinde, pokud je tato funkce pro me dulezita.
Schovavaji to za trapne marketingove plky.
V Cesku mame nejdrazsi poplatky, nejdrazzsi vybery z bankomatu a ono si dovoli umyslne blokovat historii.
Nechci delat zadnou reklamu, ale na eBanku nema nikdo - osobni ucet.
Bez ohledu na kvalitu implementace jsou objektivne dotazy na transakcni historii obecne nejhorsi zatezi na databazi v podobnych systemech. Takze se to snazi banky nejak omezit at uz soft (predvyplnenim dotazu) nebo hard (delsi historie proste neni dostupna).
U názoru musí být uveden autor, nemusi nemusi (neregistrovaný)
Vy jako clovek z oboru, muzete mi prosim uvest Vas kvalifikovany odhad kolik muzete takovy 1 vystup z databaze stat v realnych Kc i s ohledem na poplatky za elektrinu, klimatizaci, opotrebeni HW a pri platu zamestnancu, kteri system vyvyjeli jako 2000 Kc za Hod s pracovni dobou 24/7 ? Dekuji, urcite nejen ja jsem na ten odhad zvedavej.
> Verte tomu, ze je to pouze spatne naprogramovane a uz jsou lini to opravovat.
Klidne muzu verit tomu, ze v konkretnim pripade to tak je (ackoli k tomu nemam zadne podklady, ale viru mi nikdo vzit nemuze ;-), ale to nic nemeni na faktu ze dotaz ktery ma casove omezeni muze byt pro databazovy server az radove jednodussi nez stejny dotaz bez omezeni delky historie. A vy ten seznam plateb (nebo cehokoli podobneho) ocekavate nejvyse za par sekund. A nejste jediny, ve stejnem okamziku mohou chtit stejne "obtizne ziskatelna" data desitky dalsich lidi...
Je rozdil jestli databaze hleda nase platby mezi desitkami milionu zaznamu, nebo jenom mezi miliony protoze vi ze na prilis stara data uz se vubec koukat nemusi.
No a neslo by udelat nejaky kompromis - napriklad vyplivnout vypis transakci do formatu CSV a ten nabidnout ke stazeni? To generovani by mohlo klidne na pozadani probihat v nocnich hodinach a vypis by byl k dispozici nasledujici den. Takovych kompromisnich reseni by se dalo urcite vymyslet vic - malokdo potrebuje vypis za poslednich X let dostat okamzite.
A) Od banky, ktera vydelava miliardy rocne, ocekavam, ze ma HW ktery to zvladne "s prstem v nose".
B) Nevidim problem v tom, nechat si poslat vypis mailem (samo zdarma), tam muze byt zpozdeni i nekolik hodin.
C) Existuje taky tmp table, takze lze napriklad udelat to, ze v okamziku loginu do ni zacnete cpat veskere pohyby souvisejici s danym uctem, tim ziskate cas a pak uz budete prohledavat podstatne mensi DB. Aby se to nedelo zbytecne, tak bych na web implementoval volbu "uplne vypisy", ktera by byla defaultne neaktivni.
Pokud srv pri kazdem dotazu na pohyby uctu prohledava kompletni db vsech uctu, tak to implementoval idiot, co vzivote db nevidel.
Ad A) Bohuzel, tohle nezvladne zadny HW "s prstem v nose". Musime si uvedomit ze tabulky s historiemi plateb maji desitky az stovky GB, samotne indexy k nim jsou minimalne v radu gigabajtu. Z toho vyplyva ze tohle vzdy resi databaze ctenim z disku misto z pameti, coz je z hlediska databaze "drahe". Navic je takovahle operace hodne citliva na mnozstvi paralelnich dotazu, takze kdyz se chce na svou platebni historii od zacatku podivat dvacet lidi najednou, vznika problem.
Ad B) S tim souhlasim, uz jsem na to odpovidal vcera (je to o par prispevku vys)
Ad C) Je to zajimavy napad, ale obavam se by to bylo jeste horsi, protoze by se tak "drahy" dotaz spoustel na databazi i pro ty klienty, kteri se na seznam transakci vubec podivat nechteji, tj. databaze by tuhle operaci delala zbytecne. Naopak volba "uplne vypisy" je v danem pripade takrka idealni reseni, viz vyse prispevky tykajici se eBanky.
"Pokud srv pri kazdem dotazu na pohyby uctu prohledava kompletni db vsech uctu, tak to implementoval idiot, co vzivote db nevidel."
Naopak. Pokud je to udelane takhle, tak to zrejme implementoval nekdo kdo vi jak se delaji relacni databaze. (Muzeme se bavit o detailech typu archivace neaktivnich uctu apod., ale myslim ze do takovych detailu zachazet nechceme)
naprosto stejne jako by rozhodujici pro cenu automobilu byla nalepka na podlaze nekde pod sedackou, takovy je totiz realny primer ceny vystupu z databaze vzhledem k nakladum na vyvoj a provoz systemu a pocet jeho uzivatelu, kolik utratite korun vy, kdyz si nechate vyhledat v ramci jednoho adresare nejaky textovy soubor ? Nejsou tyhle debaty trochu smesne?
No jo, jenze na to aby vedela, ze nepotrebuje koukat na 10 milionu zaznamu, ale jen na milion potrebuje nezanedbatelne systemove zdroje (treba misto na disku a zpracovani indexu = CPU+memory+bandwidth)... - ano je to ulehceni, ale casto zdaleka ne tak velke, jak by se mohlo zdat...
Vas dotaz je zcela mimo misu. Predevsim jste zapomnel zahrnout nejpodstatnejsi udaj, ktery vsechny zminene veliciny ovlivni a sice konkurencni pocet transakci, ktere je treba uvazovat pri zpracovavani tohoto dotazu. Ono Vam totiz muze ve svem dusledku vyjit treba to, ze kdyz ten uzivatel, co chce nad celou databazi nejaky udaj a bude tam sam, tak tento uzivatel Vas stal X, pokud techto uzivatelu Y, tak to bude limitne pouze X*Y, ale pokud to bude stale jen uzivatel X a Z dalsich uzivatelu bude delat jine veci, tak to nemusi byt limitne X*Z, ale X*Z*M - kde M je naprosto nedefinovatelne a zalezi pouze na statistice, reps. simulaci operaci tech Z uzivatelu... - pokud vite co znamena izolace transakci tak asi vite jakym smerem mirim. Doufam, ze kazdy, kdo by chtel davat 'kvalifikovany' odhad Vas na to upozorni a neplacne vysledek, kdyz dostal tak naprosto neuplne zadani... - asi take nebude odpovidat na otazku kolik je v absolutni _ciselne_ hodnote 1 + X, kdyz vite, ze X je obor prirozenych cisel.
Prominte ale muzete mi vysvetlit tedy, jak si na sebe vydelaji dle meho nazoru mnohem narocenjsi sluzby, kde je napr. jeste navic zatizen datovy provoz velkymi obrazky apod. ? a pritom se jedna take o ruzne vystupy z databaze, pod heslem atd., a treba i s mnohem dynamicteji generovanym obsahem - nezda se mi, ze i pri slusnem vydelku z reklamy, by se jednalo o vydelek vyssi, nez primym poplatkem zivena sluzba. Pokud by naklady nebyly smesne, musel by za takovym projektem stat silny invetor a v budoucnu dojit k zpoplatneni, ale ejhle on to casto provozuje i 1 student a dlouho, tak to prosim nechapu.
No to co jste jmenoval muze byt sice datove znacne narocne, treba i nekolikaradove (z hlediska databaze) jak na bandwidth tak datove uloziste/sklad. Nic to vsak nehovori o narocnosti operaci nad temi daty - nevim o jakych projektech mluvite, ale nedovedu si predstavit studenta jak jednak financuje, ale hlavne provozuje skutecne system jehoz beh je opravdu 24/7/365 a jehoz vypadek muze byt bezne definovat pouze jako 20s v ramci kalendarniho mesice (a tento cas se neprenasi do dalsich mesicu) - vite, bavime se o aplikacich zcela odlisneho charakteru, narocnosti, zabezpeceni (a to vcetne pozadavku definovanych v zakonech) apod. a tezko lze jakkoli srovnavat... - zejmena zminka o provozu projektu studentem (nic proti nim, taky jsem jim byl) - tedy one-man-show reseni - mne utvrzujete, ze vlastne vubec netusite co provoz bankovni aplikace takoveho rozsahu (a to zcela pomijime fakt, ze WWW front-end je pouze velmi mala cast (pod 10%) bankovniho IS) vlastne obnasi a jak je treba jej technologicky (vcetne redundance) zabezpecit.
vychazim z toho, kolikrat takovy pozadavek je v prumeru na databazi vznesen, hm
a potom z ceny poplatku navic za to, ze je to zakaznikovy umozneno, hm
a tapu nad rozdilem jak se prace s temito daty tak vyrazne lisi od jine zabezpecene prace s jinymi daty, ktera zvlast spoplatnena vsak neni, hm ?
proste neverim, ze se realne naklady pocitaji v tak velkych sumach, pri poctu klientu..(at delam co delam)
pripomina mi to argumentaci u free sms, nebo cz nicu, samozrejme ze ty systemy stoji velke penize, ale realna cena na 1 zakaznika, hm
Realna cena systemu na jednoho zakaznika byla takova, ze eBanka jeste do nedavna vykazovala provozni ztratu a to i pri +- 100.000 klientech. Nechci hodnotit uroven a efektivitu vynalozenych prostredku, pouze to konstatuji jako fakt. Zrejme si kazdy mysli, ze provoz IS je podstatne levnejsi nez provoz kamenne pobocky - cim to, ze dnes (i kdyz mnozstvi klientu tak razantne nestouplo) ma eBanka kladnou financni bilanci, ma podstatne hustsi sit klientskych center (pokud mne pamet neklame, byly puvodne 4-6), ma podstatne hustsi sit vlastnich bankomatu... Souhlasim s Vami, ze cena provozu a tzv. udrzby IS neroste linearne s poctem zakazniku, bohuzel u takoveho systemu neni zanedbatelna a uprimne, radsi sverim penize bance, ktera neco skutecne vi o zabezpeceni svych systemu a dba o ne a ne jako jina nejmenovana banka (asi tak radove vetsi), ktera neni schopna udelat ani bezpecne elektronicke bankovnictvi (teda po letech uz jo, ale to co vypustila do sveta je do dnes dost velky pruser) a ani neni schopna na konci 20. a na zacatku 21. stoleti vyuzit potencial datovych siti tak, ze se ji IS samovolne sesype diky archaickemu zpusobu komunikace bunek mezi sebou - a to na nekolik dnu - bylo to v roce 1997 (?) pred vanocemi, fakt posusnanicko...
ČLÁNKY DO MAILU