Helios Green aneb nejsprasenejsi aplikace kterou znam

Berte jako podnet k zamysleni jak se da aplikace sprasit.

Jde o ERP, podle chlubeni se dodavatele (LCS) "nejlepsi ceske".

Co me ponouklo toto sem napsat ? Tebas dnesni zkusenost. Vyrobite si uzavetelske pole, to se nejak jmenuje v databazi a samozrejme mu date nejaky nazev ktery uvidi uzivatele. Ovsem ten nazev nesmi obsahovat slovo nazev ani slovo reference (a to ani s diakritikou). WTF ??? Kdyz obsahuje, tak vam tahle uzasna vec misto nej zobrazi ve formularich databazove jmeno, navic neuplne a jako bonus nelze s polem pracovat. Idiota ktery neumi pracovat se stringovou popiskou a nazvem databazoveho pole by bylo zahodno povesit za koule do pruvanu.

Rikate si mozna drobnost ? OK, muzu pokracovat. Dalsi "drobnosti" je, ze temer veskere chybove hlasky jsou v podstate ladicimi vypisy. Pro usera uzasne. Specielne kdyz mu ta hlaska rika, ze ma vyplnit policko XYZ a k tomu mu vypise SQL query ...

Nebo, existuje XML rozhrani, pres ktere muzete se systemem komunikovat z jine aplikace. Rozhrani poslete nejakou zpravu a vrati (nekdy) odpoved. Kupodivu i kdyz vrati ze se nepovedlo, zustane v DB cosi, co neni videt z aplikace protoze tomu neco chybi. Nebo naopak, vrati ze se povedlo, zel v DB neni nic.

Variantne uzivatel cosi dela a vyskoci mu nejake to hlaseni ptajici se na potvrzeni. Jenze to hlaseni vyskoci za oknem ve kterem neco dela => ono je "tuhe" a uzivatel nevi co se deje.

Pripadne se muzete pobavit s "tenkym" klientem, ktery pri rolovani gridu vytizi dvojjadro bez problemu na 80+% a roluje tak 10radku/s (pri tom zatizeni). Schvalne, jak rychle odroluje grid v excelu o 100k radku ? A s jakou zatezi ?

Jako tresnicku pridavam, ze tutez "vec" pouzivaji jakozto helpdesk a jen prihlaseni je tak na 10-15 minut. Pridani prilohy je pak 15-20 operaci ktere musite udelat. Nebo ze aktualizace znamena stahovani prakticky kompletni aplikace (cca 100MB) ... (diff k nim nejspis jeste nedorazil).

Pocitam ze nejsem sam kdo ma zkusenosti s touto hruzou, takze sem klido pripiste svoje zazitky.

Na to lze říci jen: No fuj :)

Bohužel náš trh s ERP i sklady obecně je na tom vážně špatně, doufám že se dostanu k vývoji vlastního jádra, abych využil zkušenosti z Dynamics AX.

Mno skladovej system pouzivame taky. Je tam bug ze dochazi k deadlocku (nekdy). Dodvatel to opravit neumi, protoze nevidi do zdrojaku a vyrobce to opravit nechce, protoze dodavatelske upravy .... ale neni to tak hrozny narozdil od ERPcka.

Ackoli neujsem profesi programator, prijde mi, ze takovou prasarnu bych si nedovolil prezentovat ani jako svoje dilko.

Vesele prihody muzou pokracovat trebas tim, ze erpcko ma jakesi moduly (sklad, mzdy ...) a podle chovani je zrejme, ze ac okenka vypadaji podobne (dalo by se rict i stejne) tak se chovaji ruzne => tam kde vam rekneme v modulu X funguje vyber vsech dokladu ctrl+a, tak v modulu Y se totez dela ctrl+shift+a.

Samozrejme o tom ze by patche vychazely pro jednotlive moduly (abyste si kvuli mzdam nemuseli rozbit sklad) si muzete nechat maximalne zdat.

Dalsi prca jsou obecne nazvy poli. Pole se nejak jmenuje v databazi a to je prakticky jedine na cem se da s nekym dohodnout. Pole pak ma nejaky nazev jako popisku (viz predchizi zabavny post) ale ta se jeste nemusi zobrazit na formulari, na nem muze totiz byt napsano neco uplne jineho.
Takze uzivate si otevre formular a vidi rekneme "Cislo dokladu: xyz", chce hledat => zapne si fitr a hleda cislo dokladu ... nj, jenze ono se to pole jmenuje trebas reference subjektu (jak to ma chudak vedet ?) a v databazi se muze jmenovat jeste nejak uplne jinak. Fakt uzasny.

My jsme nad tímhle "veledílem" jednou implementovali náš MIS a co si tak pamatuju, tak to byl docela zážitek ;D Já naštěstí na tomhle projektu nedělal, zatím mě "postihly" leda záležitosti běžící nad daty z MFG či SAPu :-D Pracovat s Heliosem a komunikovat s LCSkou, tak to pevný nervy! ;D

EDIT: Když jsme u těch výrobců - tak mi kolega říkal, že onehdá hlásil výrobci chybu v MIS Alea... Dala se sice "pracně obechcat", ale taky jednoduše odstranit... Odpověď? "O problému víme, ale nebudem jej řešit"... Ještě, že tuhle "OLAP platformu" u nových projektů už nepoužíváme a jede to teď na jiné technologii :-D

Panove, pokracovani zazitku (skoro by zaslouzilo presun do vtipu). Ad zminene nazvy poli.

"reseni" :
<key name="NotRelationColumns" value="lcs_uda_test_refer,lcs_uda_test_nazev"/>

Toto praskene do konfiguraku, samo nezdokumentovano, jak muzete videt, syntax musel delat kreten, ktery XML nechape ani na urovni MS (kdo to kdy videl by se v XML neco oddelovalo carkama v parametru tagu). Jako bonus to funguje (jako vse od LCS aneb Asseco) tak nejak napul. Policko sice funcni je (nebo aspon tak vypada), ale popiska nikoli (zobrazi se neuplny nazev v DB).

Kua Jezevec neděs mě, mě od konce měsíce čeká implementace MIS ve firmě, kde je jako ERP právě HeG :-D :-D

No.. muzu pokracovat, pouziva se tu EDI a chodi to jako formatovany txt (pevne definovany format). Jednoznacny a jednoduchy pozadavek = zachovat funcionalitu = import txt souboru. Nelze. Potrebuji XML (jak snim umi, viz predchozi).

V jedne firme, kde jsem delal ajtaka, nasadili system Notia. Bezi to na oracle eneterpise server a umi to docela dost veci, navic se to tvari dost pouzitelne. Jako perlicku uvedu, ze ta firma notia porada mistrovstvi v powerballu v CR :)
O heliosu jsem slysel ze je hodne tragicky, navic to bezi jen na wokennim serveru.

Bezva, tak jako bonus ono "reseni" zpusobi, ze se ta jejich aplikace cela zhrouti (nikdo nemuze nic pridat).

Tak jsem opet zde, s dalsim dilem serialu.

LCS (Asseco) provozuje helpdeskovy system ve svem sprasenem systemu. Nejen ze prihlaseni je tak na 5 minut, ale vymysleli v posledni verzi uzasnou featuru. Pokud nema uzivatel pravo na export dat, nema zaroven ani pravo na ctrl + c. No a jelikoz toto pravo samozrejme jako zakaznik nemate (dalo by se tak dostat k libovolnym datum, protoze prava jsou pro ne neco jako UFO pristavajici na Vaclavaku), tak si nevykopirujete ani data, ktera jste sami do systemu zadali. Uzasna vlastnost helpdesku, coz ?

jen poznamka... je to produkt by LCS ne Asseco, LCS byla koupena.... ale je to jen detail (ted je to asseco solutions)

Jedeme dal. Tak si predstavte, mate nejaky seznam (ciselnik) zaznamu a nastavite si, ze nad doklady typy XYZ se ma automaticky doplnit hodnota 123 (z toho seznamu). No a kdyz hodnotu 123 ze seznamu smaznete, tak ten default s naprostym klidem narve do databaze id jiz neexistujiciho zaznamu, coz navrch znamena, ze onen doklad nelze beznym uzivatelskym zpusobem nijak upravovat.
Pekne vam takto vzniknou nekonzistentni data a pri trose stesti to zjistite az po par tydnech/mesicich.

Navazuju na sve predchozi zazitky a pokracuji v osvete pro ty, kteri by se nekdy nahodou dostali do kontaktu s timto bastlem.

30 zaznamu je strasne moc. Neverite ? V roce 2010, TB databazi ... ? Mate 90 zamestnancu? To jste na tom jeste dobre, mzdove listy budete tisknout 3x. Vic nez 30 najednou je proste strasne moc a system vas posle doprdele. Jiste, stejna data ziskate z databaze dotazem bezicim sekundu, ovsem sytemu to trva minuty a tak, misto aby se vyresil adekvatni vykon, nastavi se omezeni na 30.

Mate pocit, ze spravce aplikace tu je od toho, aby vam nastavoval firemni postupy, pripadne administroval opravneni a dalsi aspekty ? Omyl, spravce je tu od toho, aby neustale resil neschopnost dodavatele. Napr ohledne navrhu databaze. Indexy si musi vymyslet sam, ovsem samozrejme, pokud neco prestane fungovat, dodavatel to svede prave na jeho indexy. Ve standardnim stavu trva takova extremne neobvykla vec, jako je pridani firmy na objednavku, bez problemu minutu i dele - podotykam, ze na naprosto nezatizenem SQL serveru. Nu coz, naflakate si tam indexy, zvetsite databazi na dvojnasobek, prikoupite za par M dalsi TB uloziste a zjistite, ze jakekoli ulozeni cehokoli trva 2x dele, protoze update vs indexy ...

Prijde vam normalni, ze system z verze na vezi umi sam udpovodajicim zpusobem osefovat databazi tak, aby vse fungovalo ? No to jste ale nekde jinde. HeG prevedete na novou verzi a zacnete se divit, ze misto Ano/Ne se vam ve formularich objevi 1/0 pripadne A/N ... proste to, co reprezentuje stav v databazi. Pak si samozrejme sami vyzkoumate(dodavatel nevyzkouma nic, jen vam posila nesmyslne odkazy na kdejakou hovadinu), ze je to tim, ze nova verze neumi pracova s typem char, tak si to alespon v uzivatelskych tabulkach prevedete na varchar a zjistite, ze stejny problem je v tabulkach dodavatele. Myslite si, ze to opravi ? Ale kdeze, opet vam posle odkazy na hovadiny, takze vam nezbyva nez to riskout, zmenit datovy typ a modlit se, aby v neblizsich 10ti letech na danou tabulku nesahal (coz se samozrejme nestane, struktura se meni s kazdou aktualizaci).

Myslite si, ze dodavatel, ktery se chlubi na svem webu ze je dodavatelem nejvetsiho ceskeho ERP ma lidi schopne programovat ? Jak naivni. Nejsem programator, ale co je to for tedy vim (narozdil od lidi prgajicich HeG). Myslite si, ze neco tak velkeho se navrhuje a programuje objektove ? :lol: Kdyby to tak bylo, tak by se preci nemohlo stat, ze nad stejnym objektem muzete pouzivat konkretni funcionalitu podle toho, z ktere strany do nej vlezete. Neuveritelne, ale celkem standardni. Prislo by vam normalni, nastavovat konfiguraci poptavek nad necim(pro znale poradacem), co se jmenuje poptavky ? Me take, ne tak vyvojarum HeG. Musite vlezt do dat. Prisilo by vam normalni nastavovat chovani a predvolene nastaveni funkcni nad seznamem funkci ? Nj, to by ste ale nesmeli byt u LCS/Asseco. Jim prijde normalni, ze si funkci pustite, vybleje to na vas tabulku, ktera muze byt pri jine prilezitosti jina, a po jejim vyplneni mackate "tajnou" kombinaci klaves "toto chci ulozit jako default".

Myslite si, ze by "moderni" ERP mel narosto normalne zvladat veci jako nastavovani uzivatelskeho vzhledu pro uzivatele/skupiny uzivatelu adminem ? Na to rovnou zapomente. Uzivatel si muze neco ubastlit a ulozit si to, ovsem pokud potrebujete neco zmenit centralne, tak musite vsem uzivatelum jejich nastaveni smaznout. Neco jako nastavit skupine X neco a Y neco jineho ... :lol: Muzete ovsem obehat vsech svych N uzivatelu a ponastavovat jim to rucne.

Jeste neco k pravum, neco uz sem zminoval, tak rada pro pripadne malo privilegovane uzivatele. Pokud vas neco zajima, staci kdyz v systemu mate pristup k filtrum (i radkovym). Do tech se da uplne vpohode vlozit query. Na webu se tomu rika sql injection a povazuje se to za jednu z nejzasadnejsich chyb jakou muze web mit. A pokud neznate strukturu databaze, nebojte se, system vam rad napovi, staci kdyz si do tzv "velkeho" filtru date vlozit vyraz. Nabidne vam to pekne seznam vsech policek. A co muzete s temer 100% jistotou ziskat ? No protoze na vsech dokladech je policko pachatel, tak pokud ho vidite, jako ze na 99% ano, tak mate pristup k veskerym udajum o zamestnancich - rodna cisla, mzda ...

Wow, ten posledný odstavec je perfektný. Mať niečo takéto vo veľkej spoločnosti, alebo v banke to by bolo peklo. :-)

Mno ... pouziva to dcerinka CEZu I&C Energo ... maji tusim 10k zamestnancu (zajistujou servis pro CEZ) .... nechapu jak stim muzou zit. Sice v tom asi nedela moc lidi zaroven, ale pocitaj jim v tom vejplaty.

Ad vykon, 50lidi zaroven, nedelajicich prakticky nic jinyho nez vytvareni dokladu (objednavky, vydej, prijem ...) sezere 2x4 na procesoru SQLka na 100%. To myslim celkem slusne vypovida o uzasnem navrhu databaze. Nacteni prehledu dokladu pak trva v nekteryh pripadech i 30+s, insert do DB i minutu a vic. Tzv "tenky" klient sezere vpohode dvoujadro na 100%. Zato tzv "aplikacni" server nedela nic (ale pro jistotu se kazdou noc restartuje IIS).

Co se bezpecnosti tejce, proste se spoleha na to, ze uzivatel je dement, kterej nikam nepoleze.

Kdo studoval na ZCU, mohl by referovat o kvalite databaze a ovladaci aplikace STAGu, pomalosti a molochovosti portalu a kravskemu predzapisu, ktery "zvenci" nefungoval a kdyz, tak jen velmi omezene a na fakultach mimo trojuhelnik take dovedene k dokonale nepouzitelnosti (tedy jeste pred dvema lety to tak platilo, ze se zadal pozadavek na misto na prednasce / seminari a za dve minuty to bud bylo, bylo obsazeno nebo doslo k chybe, to vse pak nasledovane celodenni seanci s papirovanim)... Na FAV to bylo jinak, tam se naklusalo do ucebny, povybiralo a za pul hodiny bylo i v indexu.

Citace:

---

Původně odeslal peta303

Kdo studoval na ZCU, mohl by referovat o kvalite databaze a ovladaci aplikace STAGu, pomalosti a molochovosti portalu a kravskemu predzapisu, ktery "zvenci" nefungoval a kdyz, tak jen velmi omezene a na fakultach mimo trojuhelnik take dovedene k dokonale nepouzitelnosti (tedy jeste pred dvema lety to tak platilo, ze se zadal pozadavek na misto na prednasce / seminari a za dve minuty to bud bylo, bylo obsazeno nebo doslo k chybe, to vse pak nasledovane celodenni seanci s papirovanim)... Na FAV to bylo jinak, tam se naklusalo do ucebny, povybiralo a za pul hodiny bylo i v indexu.

---

bajecny STAG zavadeli pred 6 lety ve Zline na UTB. Chyby systemu se omlouvali vyvojem a testovanim. Ja 4 roky po promocich jsem se opet setkal s timto "super systemem" a opet stejne chyby. Takze alespon na UTB se nic nezmenilo.

A mame tu dalsi pokracovani serialu ;). Viz vyse zminovane indexy. Dodavatel se(presne dle ocekavani) ohani tim, ze tam mame svoje indexy a ze je to pomale kvuli nim(inserty samo). Ale kdyz tam ty indexy nebyly, bylo to jeste 100x pomalejsi(na vsem ostatnim, protoze selecty) :D. Minuly tyden se samozrejme jedna nejmenovana odbornice pres databaze (select je pro ni sprosty slovo) vyjadrovala v tom smyslu, ze indexy nicemu nevadej a na namitky, ze to zpomaluje inserty rekla "ale jenom trochu". Mno ono u 120GB databaze to bude asi "trochu vic" ;).

Jinak celkem standard. Sefko dodavatele se svoji ekypou nasliboval, jak vsechno do dnes vyresi :D a dnes se po 15:00 ozval nakej jejich mamlas a ptal se, co ze to vlastne ma resit a plkal, ze sme nerekli co konkretne je pomaly (trace z databaze s odchycenymi 30s query mu je zrejme malo). Je uplne jedno s kym od nich se budeta bavit, pokud je to obchodak/managor, naslibuje vsechno. Pokud je to kdokoli jinej, posle vas doprdele. Jediny co uz od minulyho tejdne resej je, kde najit duvod nefunkcnosti na nasi strane (pro sychr mame HW dimenzovanej min 10x vejs, nez byly jejich pozadavky pro danej pocet useru). Navic pres nekolikere upozorneni ze se bude testit vykon systemu si nerekli co kde mame pozapinat a ted se ohanej tim, ze nemaj logy.

BTW: Pro znalce. Zkuste si predstavit insert, kterej obsahuje cca 5ti az 10ti nasobnej case + takovych 5 subselectu + joiny pres varchar ... taky vam vstavaji vlasy hruzou ? Vase nocni mura ? Ale kdeze, to je tak prumernej stav tohodle zazraku.

Citace:

---

Původně odeslal Jezevec

BTW: Pro znalce. Zkuste si predstavit insert, kterej obsahuje cca 5ti az 10ti nasobnej case + takovych 5 subselectu + joiny pres varchar ... taky vam vstavaji vlasy hruzou ? Vase nocni mura ? Ale kdeze, to je tak prumernej stav tohodle zazraku.

---

Se spatnym navrhem databaze se moc delat neda....leda pridat vic RAMky a pouzit SSD, pripadne nejak hodne dobre udelat indexy + vytunit SQL server (pokud to jde). Ale nekdy to proste uz lip udelat nejde a pak se stane, ze jeden join zabere 6 hodin a clovek s tim proste nic nenadela .8GB RAM+ SSD + MySQL a brzdou je 4GHz CPU core-i3. Ten join pres VARCHAR me ale pobavil :)

Citace:

---

Původně odeslal Jezevec

Mno ... pouziva to dcerinka CEZu I&C Energo ... maji tusim 10k zamestnancu (zajistujou servis pro CEZ) .... nechapu jak stim muzou zit. Sice v tom asi nedela moc lidi zaroven, ale pocitaj jim v tom vejplaty.

---

Nejsme uz dcera CEZu a zamestnancu je cca 1500. Kdyz se pocitaji vyplaty, tak je system naprosto nepouzitelnej a neda se s nim normalne delat.

2wong: kdyz sme byli na navsteve (uz to bude tak 2 roky), tak nam tvrdili, ze vejplaty pocitaj 3 dny v kuse :D. Jinak ze si sem tam nekdo vyrobi objednavku na dily.
2petrik: dve ctyrjadra + 64GB RAM ti prijde malo ? + SAN cx3-10 (FC, SQL ma pro sebe dokupy 18x 15k disk v R10) ?

Jezevec: ano tak nejak to je, proto jsem opravoval pocet zamestnancu... :(

Citace:

---

Původně odeslal Jezevec

2petrik: dve ctyrjadra + 64GB RAM ti prijde malo ? + SAN cx3-10 (FC, SQL ma pro sebe dokupy 18x 15k disk v R10) ?

---

Hm, vsadim se, ze kdyz se zbavite toho SANu a nahradite ho jednim, nebo nejlepe nekolika X25-E/M s dobrym HW RAIDem R10, tak se vykon zmnohonasobi, tedy za predpokladu ze se neco z tech disku vubec taha. SAN ma totiz jeden problem a tim jsou latence. Porovnej latence FC (tedy neco ala ethernet) vs. lokalni SATA/SAS disk/SSD. Navic tech 15k disku vpoli muzes mit treba milion, ale latence budou porad radove horsi nez u jedineho SSD. V jedne firme jsem udelal obyc server s raptorem a 16GB RAM a oracle na tom behal rychleji nez na nejakym brutalnim IBM POWER serveru a to jen kvuli tomu, ze tam bylo nejaky hyper mega ultra SAN pole (celkem za miliony), ktery bylo desne pomaly...

SAN ma podle me smysl u clusteru, kdy to bez nej nejde (jde, viz google :) ), ale pro jeden server existuji lepsi vecicky a vyrabi je napr. firma Fusion-iO :)

http://www.fusionio.com/products/iodriveduo/ tahle hracka uz asi neco zvladne :)

NAND Type Single Level Cell (SLC) Multi Level Cell (MLC)
Write Bandwidth 1.4GB/s (32K packet size) 1.0GB/s (32K packet size)
Read Bandwidth 1.5GB/s (32K packet size) 1.4GB/s (32K packet size)
IOPS* 185,022(4K read packet size)
129,699(75/25 r/w mix 4K packet size) 122,601(4K read packet size)
121,008(75/25 r/w mix 4K packet size)
Access Latency <50µs Read <80µs Read

Mimochodem tohle DUO ma dvojnasobne latence nez "single", ktery ma 26µs, coz je proste mazec. To uz ma bliz k RAMce, nez k diskum.

Dalsi vec je pocet jader a skalovani vykonu. Nezapomenu, jak jsem do onoho obyc serveru s oraclem dal misto 3GHz dualcore 2.9GHz quadcore a vykon sel kam? vykon sel do kytek (4x pomalejsi), protoze vsemocny buh Oracle zvolil nejaky suboptimalni algoritmus nebo co a pomohla az nova verze Oracle serveru... jen mimochodem v te dobe jsem o SQL nemel ani paru, ten Oracle resil jeden dost zkuseny DBA..

Netusim jak je na tom MS SQL vs. skalovani vs. multithreading, ale napr. vim, ze MySQL pro jedno spojeni pouziva jen jedno vlakno, takze jader muzu mit treba deset a je mi to prd platny (proto ho provozuju na OC dualcore).

Tak na tom SANu neni jen SQL samo a vzhledem k velikosti databaze vs velikost dat/indexu se to vpohode vejde prakticky cely do RAMky, ty disky i podle stats vicemene jen zapisujou, cteni je naprosty minimum. Jak sem psal, zatezuje to CPU. A to "by woko" 3x vic nez "zastarala" PB verze. Je proste videt, ze nekdo optimalizoval az zoptimalizoval a zakaznici at se poserou. Druha vec je, ze paac M$, se neda rict, estli dalsi CPU pomuze nebo ne. M$ je na tom obecne tragicky a navic se to jejich SQLko chova tak kokotsky, ze kdyz jedinej user posle "pekny" query, tak sezere vsechny CPU a neprihlasis se ani na konzoli ....

2wong: mati je mzdovka, pocita tusim neco kolem 150 vejplat a vypocet trva mozna minuty na obyc PC, ale dyl IMO ne (schvalne se poptam).

Ze to bezi na MS samozrejme ani nekomentuju, to je kapitola sama pro sebe...

Na co bych se zameril je tuning nastaveni toho SQL serveru. Vubec netusim, zda jde vubec neco nastavovat, MS SQL jse nevidel ani z vlaku, ale vim, ze napr. dobra vs. spatna konfigurace MySQL muze znamena RADOVY rozdil ve vykonu (klidne i nekolik radu). Zasadni vec je napr. mit pokud mozno temporary tables v RAMce, zamezit double-bufferingu FS OS+SQL a pod.

Jestli tam ale ti autori provadeji JOIN pres VARCHAR, tak je zcela evidentni, ze to jsou naprosti SQL amateri a lemplove a v tom pripade pomuze leda tak zazrak... takze uprimnou soustrast a dobrou noc.

zkusim upozornit na tenhle thread, treba se to dostane az k zodpovednym mistum, nechce se mi verit ze by s tim nikdo zamerne nic nedelal...

Tak pro zajimavost, spocitat vejplaty pro 70lidi cca 2 minuty na obyc kancl PC.

2pajkus: Ono by se to muselo cely vzit, zahodit a zacit od nuly, nic jinyho stim delat prakticky nejde.

Citace:

---

Původně odeslal Jezevec

Tak pro zajimavost, spocitat vejplaty pro 70lidi cca 2 minuty na obyc kancl PC.

2pajkus: Ono by se to muselo cely vzit, zahodit a zacit od nuly, nic jinyho stim delat prakticky nejde.

---

me je naprosto jasny, jak to vyvijeli. Zacali s hodne spatnym navrhem databaze a pak na to zacali nabalovat nove anove funkce, az z toho vznikl dnesni stav. PRESNE totez se totiz stalo v te firme kde ted pracuji. Nejdriv zacinali jen s pomoci csv souboru (!!), pak nasadili databazi a jelikoz tomu nukdo nerozumel, pouzivali to stejne jako ty csv soubory. Ted je na tom naprosto tragickem navrhu desitek databazi postaven cely system, tedy desitky a stovky tisic radku SQL a java kodu a nejde s tim nic delat nic jineho, nez kupovat silnejsi HW ;)
Alespon tu neprovadime JOIN pres VARCHAR, zato databaze jsou casto sirsi nez vyssi (vic sloupcu (bezne 100 az 200) nez radek) ;)

Tak co se tohodle tyce, oni prave relativne nedavno (4 roky) presli na .NET. A misto aby ten prechod vyuzili k predelani databaze a aplikace, tak proste cpy&paste pouzili to co meli => funguje to jeste hur nez predtim.

Panove a damy, dobre se posadte, jedeme dale.

Chcete odstavit celou firmu z provozu ? Staci jednuducha vec, 12x pokus o login na kazdeho usera a dotycny se (zatim neznamou) dobu proste neprihlasi. Vypada to na +- 15 minut, ale tech 15 minut samo nesmi nastat zadny neuspesny login. Dokumentaceo teto funcionalite taktne mlci, moznost administratorskeho zasahu podle vseho veskera zadna. Idealni jako nezjistitelna pomsta na kohokoli, staci vedet jeho loginname. Nic se nikam neloguje, takze nezjistite kdo ani odkud. Jedine co zjistite, ze se nekdo pokousel neuspesne o login.

Omg do pitche... už se mi to blíží... Příští týden začneme z HeG dolovat data pro datovej sklad našeho MISu, to jsem zvědavej, jak "veselý" to bude :-D Ale snad když se s tím budem bavit jen SQLkem, tak by to mohlo bejt přístupnější :-D

Z SQLka ... Pro priklad, na zbozi se ti rozpocitava doprava. Jenze to funguje nekdy tak a jindy onak. Nekdy se to flakne rovnou na vydejku (radek toho produktu) a nekdy (pokud FP prijde az po vydeji) ti vznikne samostatnej doklad. => pokud tuhle informaci dolujes z DB, nestaci ti jeden select, ale minimalne dva ruzny.

Totez plati napr pro DIC, kde na organizaci mas policko DIC, ve kterym najdes DIC, ale pokud ho pouzijes, tak sis prave nas.ral do bot, protoze je tam jeste tabulka, paac organizace muze mit ruzny DIC v case a to co je v tom policku nemusi byt aktualni. Samo cast aplikace pouziva to policko, cast tu tabulku = je to nekonzistentni.

Jakmile chces nekde operovat s cislem dokladu (reference_subjektu), tak automaticky pocitej stim, ze neni unikatni (ani v ramci dokladu jednoho typu/tridy/poradace). Ty si sice muzes nastavit ze "kontrolovat unikatnost", ale proste to nefunguje => na tohle zapomen rovnou, je treba jit pres cislo_subjektu. Technicky muzes mit v systemu dve (i vic) ruzny poptavky/vydejky/faktury/... se stejnym cislem (to co vidis navystupu). By me zajimalo, jak bys to vysvetlil financaku.

Obecne de kazda vec udelat min 3ma naprosto datove rozdilnejma postupama (nekdy ale klido deseti). Napr rekneme ze zakaznik si rozmysli nakup => bud se smaze doklad uhrady => zustane nezaplacena faktura (a nejsou vydejky, takze z ucetniho hlediska je to OK). Nebo se udela storno toho dokladu = vznikne zapornej, opet OK. Nebo se da vystavit dobropis .... z pohledu zakose dycky stejnej vysledek, z pohledu spracovani dat nocni mura. Zalezi samo jak moc kreativni jsou zamestnanci.

Sorry ze ted budu trochu OT, ale zajimalo by me, co se vam libi vic: co nejvice logiky v db, tedy foreing_keys, triggery,procedury, eventy a pod, nebo naopak co nejvice logiky v aplikaci?

Ja osobne davam prednost tomu, kdyz je logika jak v DB tak i aplikaci.

Ale proti gustu ....... tak jak to tady ctu tak si nekdo poridi Helios green, kde logika chyby jak v databazi tak aplikaci ....

IMHO tohle jsou stejně jen takový zoufalý výkřiky. Každej systém má mušky, mouchy i masařky. Všude se něco najde... A nebo je to za cenu kompromisů a pekelný ceny.
Stejně tu nic nevyřešíme :)

Citace:

---

Původně odeslal Petrik

Sorry ze ted budu trochu OT, ale zajimalo by me, co se vam libi vic: co nejvice logiky v db, tedy foreing_keys, triggery,procedury, eventy a pod, nebo naopak co nejvice logiky v aplikaci?

---

IMO by to melo byt vyrovnany, rekneme ze struktura DB by mela jasne vyjadrovat vztahy mezi tabulkama a mela by zajistit v maximalni mire konzistenci dat = nedovolit aplikaci to rozjebat a aplikace by mela resit aplikacni logiku = co se kde bude scitat ... protoze to zase nema co delat v databazi. Mozna jinak receno, zmena legislativy by nemela vest ke zmene databazovych struktur. Ty by mely byt maximalne stable a menit se jen naprosto minimalne.

2Marty: Sak ja se nesnazim nic vyresit, ony jsou totiz chyby a chyby. Ja kdyz budu mit nekde neco blbe, tak z pripadnyho zakaznika aspon nebudu delat debila a budu se to snazit napravit.

Citace:

---

Původně odeslal Marty

IMHO tohle jsou stejně jen takový zoufalý výkřiky. Každej systém má mušky, mouchy i masařky. Všude se něco najde... A nebo je to za cenu kompromisů a pekelný ceny.
Stejně tu nic nevyřešíme :)

---

SOuhlasím s Martym. Vždycky je to otázka kompromisu. Dokonalá aplikace neexistuje.
Každý vývoj něco stojí a to se pak odráží na ceně softwaru a maintenance. Pokud chci levné ERP, měl bych počítat s tím, že to bude mít mouchy. Problém nastává ve chvíli, mohu-li za stejnou cenu sehnat o řád kvalitnější ERP. Zde je pak jasné manažerské selhání (kapříci) při výběrovém řízení daného ERP.

P.S. A osobní zkušenost? Jezevec má pravdu. Jednou jsem tenhle bazmek (HeG) taky potkal na projektu a nerad bych to opakoval... ;-)

Dokonalá aplikace samozřejmě neexistuje, problém je v tom, že občas se prostě "povede" tak špatný návrh, že to zezačátku jakž takž funguje, tak se na to balí další a další funkcionalita, něco jako když děláte kouli na sněhuláka... Jenže pak se aplikace dřív nebo později dostane do stádia, že to prostě "takhle dál nejde" a teď babo raď. Předělat to stojí spoustu času, čas = peníze, peníze, který autorům aplikace nikdo nedá (zákazník by ideálně "neměl nic poznat", minimálně ne v podobě výpadků při přechodu na "nové" struktury)... Jenže to je často dost obtížné prosadit či v případě skutečně "zmaštěných" návrhů prakticky nemožné udělat... Tak se holt ta kára tlačí dál a v tichosti se doufá, že to ještě chvíli vydrží, než z toho bude komplet průser...

Ad náš současný projekt - tak o SQL dotazy a "dodávky dat" se tam díkybohu bude starat firma, která se "heliosem živí", takže my se v tom snad rejpat nebudem muset, teda pevně doufám, po tom, co tady tak čtu...

K otázce Petrika - ono je to jedno s druhým, ideální je skloubit oboje, u menších aplikací, které jsou "méně náročné" bych si dovolil tvrdit, že nějaká "prasárna v mezích funkčnosti", která je takříkajíc "vyretušovaná" silnějším HW, se prostě nějak "přežije", tam jde o to, aby byla hlavně dobrá ta "aplikace", tj. to, co uživatel "vidí"... Průser nastává v případě, že si firma řekne "hurá, prodává se to, tak to trošku rozšíříme, ještě víc, ještě".... A viz začátek mého postu :wink:

Obojí by mělo jít ruku v ruce, nicméně jak říkali i naši předkové, dokonalá jsou jen díla boží, takže je potřeba opravdu hledat kompromisy, protože "dokonalou" aplikaci by možná někdo dokázal napsat, ale umřel by hlady, protože za cenu adekvátní nákladům na vývoj by to asi nikdo nekoupil :-D

Tak pánové....
pro Vás rádoby chytrálky.

1) pole máte za barákem, to co nazýváte polem je atribut. ANO, uživatelský (UDA) atribut, který zakládáte Vy nemůže mít ve slově postfix "_nazev" ani "_refer", a to protoze se dynamicky zpracovavaji formuláře a tyto postfixy automaticky určují, že se jedná o vztah.
2) ad servicegate.asmx -> to webové rozhraní, jak vy píšete o tom že někdy něco zůstane někdy ne - je to jednoduché... zpracovává se to transakčně. Předpokládám že mluvíte o funkcionalite INSERT/UPDATE volání, kde se zpracovávají jednotlivé záznamy jakožto samostatné tranasakce.
3) k návrhu databáze - je dovolím si říct ve standardu slušně optimalizována. Je implementováno x desítek společností, kde pracuje naráz více jak sto uživatelů a není zaznamenáno problémů. Možná je problém v implementaci od partnerske firmy.


Howgh....

Je hezké, že se k tomu vyjádřil někdo znalý! Jsi vývojářem v Assecu?

ale tak ten atribut by asi mel mit atribut "uzivatelsky viditelny nazev"? Aspon jak to psal fox, z toho vyplynulo ze uzivateli se zobrazi databazovy nazev atributu...

No vida, pak že se sem nehlásí nováčci... Co takhle trošku nakydat hnůj i na SAP, Cognos a další známější systémy a hned se sem pár vývojářů přihrne, aby si hájili svoje? :-) A hned se nám uživatelská základna rozroste ;D

BTW musím v práci zalobbovat, ještě nemáme funkci "advokáta chudých", tj. maníka, co by prolézal net, jestli se náhodou nepíše o našem produktu někde něco ošklivýho, aby na to případně reagoval ;-)

Citace:

---

Původně odeslal D_a_v_i_d

No vida, pak že se sem nehlásí nováčci... Co takhle trošku nakydat hnůj i na SAP, Cognos a další známější systémy a hned se sem pár vývojářů přihrne, aby si hájili svoje? :-) A hned se nám uživatelská základna rozroste ;D

BTW musím v práci zalobbovat, ještě nemáme funkci "advokáta chudých", tj. maníka, co by prolézal net, jestli se náhodou nepíše o našem produktu někde něco ošklivýho, aby na to případně reagoval ;-)

---

CATIA Suxx:)

Ano, jsem vývojářem HeG v partnerské firmě Asseco(drive LCS) :-) Jen me nastvalo ze clovek co o tom evidentně moc neví, nadává na "funkcionalitu"... Doporučil bych školení / certifikaci, kterou asseco pro klientské správce / partnerské konzultanty nabízí dle smlouvy bezplatně / za drobný poplatek, nebo si pročíst dokumentační portál, kde jsou tyto informace veřejně přístupné.

ad MeLuZiNa>>>
Vždyť takový atribut tam je - lcs.nis_columns.nazev_col třída atributy, atribut Název atributu. Potom máš dole db_name... A jak říkam, v názvu může být slovo "nazev", jen musíš v atributu "DB Name" vyplnit jiny nazev, treba "auto_jmeno" ... Tak složity to zase neni. Jinak ad pravnik chudych ... nic takoveho nastesti nejsem, jen nahodou kamarad narazil na tenle topic.

Jenže ono to opravdu může být tak, že z pohledu vývojáře "geniální" aplikace je pro uživatele nepoužitelný zmetek... Někdy je potřeba se nad tím pokusit zamyslet i z uživatelského hlediska... Minimálně u prvního postu co psal Jezevec nevím, že by pomohlo nějaké školení...

- Budou pak chybové hlášky více user-friendly?
- Bude rolování gridu méně vytěžovat PC?
- Bude se pak rozhraní pro komunikaci s jinými systémy chovat lépe?
- Bude dialog ptající se na potvrzení uživatele vyskakovat před, nikoli ZA oknem (tohle mě fakt pobavilo :-D), ve kterém uživatel dělá?
- Bude aplikace stahovat menší balíky pro update?

...atd... Chápu, že někdy je to "masakr", dělám v podobném businessu, na druhou stranu ne vždy je řešením prohlásit, že uživatel "o tom ví prdlajs" a "ať nám zaplatí a my ho vyškolíme"...

co se tyce otazek bude -> to se neptate na spravnem miste. co se tyce hlasek, tak sou dvojiho typu (s dalsim delenim) - pro uzivatele(osetrene rekneme zjednodusene messageboxy) a pro vyvojare (kterym user ani nema rozumet, jen stiskknout button odeslat adminovi... )
Ad rolování gridu, tam bych viděl problém jinde, bud ma jezevec nějakou powerbuilderovou verzi, nebo mají blbě nastaveny počet načítaných záznamů. Defaultně se do gridu načte prvních cca 100 (tušim že 71 je default ale proste rekneme cca) záznamů dle aktuálního sortu, a až při rolování směrem k posledním se donačítají po dalších takovýchle skupinkách, navíc při dosažení určitého limitu to uživatele i varuje, že by mohlo načítání trvat dlouho, proto jsou v každém gridu filtry, kterými dozajista uživatel nalezne záznam který hleda rychleji než scrolováním :)

Ad rozhraní pro komunikaci - nevím co myslíš chovat lépe. Pokud myslíš "totálně blbuvzdorné" tak to nebude nikdy. Každopádně s verzí 43.x.x přišlo i rozšíření tohoto rozhraní a řekl bych ke kladu, i když jsem si na to déle zvykal. Jinak ze své zkušenosti mohu říci, že toto rozhraní používám zhruba k deseti interfacum ke zcela rozličným systémům, a jediný problém který jsem nalezl zatím, byla data na vstupu. Ale to bych řekl že je obecně problém importů.

Ad dialog za / před... :-) vím, že v některých hotpatchích verze 42.x.x se to stávalo.. ale naštěstí asseco relativně reaguje na takovéto chyby. většinou se takováta chyba opravuje v následujícím hotpatchi po NAHLASENI chyby :)

Co myslíš "menším" balíkem? :) patche jsou velikostně někde okolo 100mb, hotpatche okolo 5-20mb. při dnešních rychostech internetu to není nikterak závratná velikost, zvlášťě, když se to instaluje pouze na server, na klienta pak putuje autoupdaterem zlomek velikosti.

jinak ještě k hláškám, je pravda ze nektere asseco hlasky dohani k silenosti i nas vyvojare :-) napr. hlaska "Nastala obecna chyba, nelze pokračovat" :-)

Citace:

---

Původně odeslal mugsat

Ano, jsem vývojářem HeG v partnerské firmě Asseco(drive LCS) :-) Jen me nastvalo ze clovek co o tom evidentně moc neví, nadává na "funkcionalitu"... Doporučil bych školení / certifikaci, kterou asseco pro klientské správce / partnerské konzultanty nabízí dle smlouvy bezplatně / za drobný poplatek, nebo si pročíst dokumentační portál, kde jsou tyto informace veřejně přístupné.

---

Jen počkej, až se objeví Jezevec :-) to bude prima diskuse...

:-) uz se tesim.

Pokud vím, jezevec teď řešil něco stran problémů s tiskem vyvolaným přes XML rozhraní, nějak to kucí z Asseca nepořešili.. Myslím, že to řešíme my nějakým workaroundem ;D

Takže diskuze bude rozhodně plodná.

Citace:

---

Původně odeslal mugsat

jinak ještě k hláškám, je pravda ze nektere asseco hlasky dohani k silenosti i nas vyvojare :-) napr. hlaska "Nastala obecna chyba, nelze pokračovat" :-)

---

To je koukám všude stejný :-D Nás zase v našem systému drtila v počátečních verzích univerzální hláška "Odkaz na objekt není nastaven na instanci objektu" - což mohlo znamenat víceméně cokoliv, někdy jsem měl pocit, že to hlásí i když je špatný počasí a počítači se nechce pracovat ;D

ROFL. V Catii je "Press OK to terminate" a jediny co muze clovek udelat, je zmacknout v messageboxu OK a tim si odstrelit CATII, v nejlepsim pripade po x-hodinach neukladani:)

Mno, tisky sou trošku problematicky :-) jinak co se týče Object not set to an instance... nevím jak víte moc o programování, ale je to typicka hlaska kdyz zapomenete zinicializovat promenou, nebo nacitate null hodnotu atd :)

Citace:

---

Původně odeslal mugsat

Mno, tisky sou trošku problematicky :-) jinak co se týče Object not set to an instance... nevím jak víte moc o programování, ale je to typicka hlaska kdyz zapomenete zinicializovat promenou, nebo nacitate null hodnotu atd :)

---

Ale jo, vím co to "obecně znamená", v tomhle případě bych to pochopil, pointa byla v tom, že to bylo v první verzi prostředí, ve které implementujeme uživatelská nastavení (tj. jde už spíš o "klikačku" než vlastní programování), a byla tehdá ještě dost zabugovaná, takže člověk kolikrát nevěděl, kde všude musí co udělat, aby se vše inicializovalo. Díky bohu, už jsem tuhle hlášku tak rok neviděl... Nejlepší bylo, když člověk nějakou delší dobu něco nastavoval, pak to vyplivlo toto a prostředí se dostalo do "nedefinovaného stavu", kdy ho člověk radši restartoval, protože nikdy nebylo jisté, co se z rozdělané práce reálně uloží a co ne ;D

Citace:

---

Původně odeslal mugsat

Tak pánové....
pro Vás rádoby chytrálky.

1) pole máte za barákem, to co nazýváte polem je atribut. ANO, uživatelský (UDA) atribut, který zakládáte Vy nemůže mít ve slově postfix "_nazev" ani "_refer", a to protoze se dynamicky zpracovavaji formuláře a tyto postfixy automaticky určují, že se jedná o vztah.
2) ad servicegate.asmx -> to webové rozhraní, jak vy píšete o tom že někdy něco zůstane někdy ne - je to jednoduché... zpracovává se to transakčně. Předpokládám že mluvíte o funkcionalite INSERT/UPDATE volání, kde se zpracovávají jednotlivé záznamy jakožto samostatné tranasakce.
3) k návrhu databáze - je dovolím si říct ve standardu slušně optimalizována. Je implementováno x desítek společností, kde pracuje naráz více jak sto uživatelů a není zaznamenáno problémů. Možná je problém v implementaci od partnerske firmy.


Howgh....

---

Jiste, databaze je tak uzasne optimalizovana, ze nad ni nemuze pracovat 30 lidi zaroven (by default samo) bez toho, aniz by se navzajem vsichni zablokovali. A dodavatel ma tak uzasne vyvojare a databazisty, ze to ani za penize nejsou schopni vyresit. A to podotykam, ze se nebavime o desitkach ani stovkach tisic.

Jiste, moje optimalizace byla jiste naprosto zbytecna, zajimave ze bez ni novy uzasny .NET nejede vubec.

Ad nazvy poli, taky uzasna funkcionalita, kdyz se pole jmenuje jinak na formulari a jinak ve filtru, ze ? Aha, ja zapomel ze je to featura (a podotykam, ze nemluvim o uzivatelskych formularich). Dalsi uzasna featura je, ze by default vsichni muzou vsechno, a jakmile se objevi nejaka nova vec, tak ji admin musi vycuchat a zakazat (protoze jinak se useri dostanou klido k vejplatam ...). Jo, abych nezapomel, na dynamicky vztahy pro jistotu prava nastavovat nejde vubec, taky dobry, ne?

Apropos, napada vas nejaky duvod proc se 10 000 zaznamu v logu maze hodinu? To bude jiste tim dokonalym navrhem databaze.

Ad grid, by default se nacita 30 zaznamu, a pak se, kdyz je monitor dost velky, nenaplni ani okno a neukazou se ani rolovaci listy (ja vim, uzasna featura) takze kazdy normalni uzivatel zije v domeni, ze uz toho tam vic neni ( jo, ja vim uzasna vec ze tam je pocet v zahlavi, tam to urcite kazdej hleda ). Mimochodem PB verze byla 10x rychlejsi ve vsech ohledech. A nechapu proc si nemuzu odrolovat 100 000 zaznamu, kdyz v blbym excelu si jich odroluji klidne mega za par vterin. Jen pro zajimavost, udelal sem si grid, prasknul do nej query nacitajici hlavicky dokladu, a ono to naprosto vpohode rolovalo stejne jako kazda normalni aplikace => statisice zaznamu behem par vterin. Prgani (teda spis kliknani) na 10 minut prace.

Ad chyby, buton odeslat adminovi je naprosto k hovnu, protoze se z nej (z toho hlaseni) jakozto admin ani nedovim co ten uzivatel delal. Takze stejne potrebuju aby mi to napsal nebo tipnul screen. Jiste dalsi uzasna featura.

Ad dialogy, vazne mam najit ta min 3+ let stara hlaseni, ze se zobrazuji okna dotazu za formulari ? Stale nevyreseno. Neumi to ani takovou trivialni vec, aby okno prihlaseni melo focus. Ano, mluvim o tom co se pusti po stlatecni ikony, kazdej blbej soft ma fokus, jen na tohle se musi jeste kliknout.

patche (sem zvedav kde mate tech 20MB):
42.30 - 105MB
42.30.40 - 91MB
42.33 - 113MB
42.33.10 - 96MB

(pro ty co netusi, tak bez tretiho cisla je to patch, s nim "hotpatch", to posledni je prvni uprave te 33 => nebali to na sebe predchozi => ten 20MB maximalne velky hotpach v realu ani vzniknout nemuze, to muze byt tak maximalne quickbuild => zakaznikem vyrvana oprava vuci jeho patchsetu, ale to je proste neco, co se standardne nevydava)

2Marty: Jo, ono to funguje - uz, oni nejak pani v LCS zapomeli v dokumentaci zminit, ze neumeji tisknout na sitovou tiskarnu, ale ze musi by nainstalovana jako lokalni. Takova drobnost co se resila tusim 3 nebo 4 mesice.

BTW: Pro vasi informaci, nekde se mi tu povaluje ten vami zminovany certifikat, to skoleni je taky uzasna vec, na ktery se clovek nic nedozvi. Ze vsech, ktery jsem absolvoval stalo za rec jediny, ktery skolil nejakej ranenej vyvojar, to ostatni bylo predcitani pripravenych plku. Jo, vubec nejlepsi bylo kdyz skolitelka zjistila, ze "ono to nefunguje tak jak rika (na moje upozorneni)" a mlela vesele dal.

----
Mimochodem, celkem nedavno sem prisel na novou featuru, kdysi slo nad prilohama zmenit zpusob ukladani do databaze a poradac vesele dal fungoval, jen nove soubory ladoval do novehoho uloziste a ty stare normalne oteviral z disku. Nevim se kterym patchem, ale prestalo to fungovat a na dotaz se mi dostalo uzasne dlouhe odpovedi uplne o hovne (a o necem jako hromadnym presunu tech souboru, si muzu nechat leda zdat, pricemz i tohle prasteny forum to umi).

Edit: Pro zajimavost, rad bych jedineho zakaznika (opravdu mi staci jeden jediny), ktery mi rekne do oci, ze je se system spokojen. Nikoho takoveho nam LCS nebyla schopna dodat. Kdykoli sme nekam jeli se podivat na nejake reseni (predevsim ohledne migrace) tak se zjistilo, ze to byl jeden velkej pruser.

:-) tak popořadě... jezevčáku vidíš to moc černě.

30lidí nad tou databází může pracovat naprosto s přehledem, aniž by se navzájem blokovali, SAMOZREJME... pokud spustíš nápočty skladových uzávěrek, je logický, že kvůli konzistenci dat se musí záznamy které se načítají zamknout... nikdo ti nezakazuje dtb replikovat a takovéhle operace provádět mimo... Pokud se ti to zamyká více, bylo by vhodné zjistit příčinu ( např z logu blokování ... )


Co se týče tvoji optimalizace, tak pokud sis přidal své indexy, může to být pokud se v tom vyznáš dozajista výkonově lépe natom, než indexy, které generuje systém při zakládání uziv. trid... :)

Default muzou vsichni vsechno... :-) co k tomu dodat,... nastav si defaultni skupinu tak aby nemohla nic :p ale to neni vada systemu, kdyz nastavis ve windows práva na disk pro everyone na všechno, tak každý nový uživatel taky bude mít práva... tak se nad tim zamysli proboha.

Ad jména na formuláři a filtru... - co na to proboha říct? POle se jmenuje pokaždý jinak, jen tam máš jiný label pravděpodobně. Nevím jestli to je zakázkový formulář, nebo to je v defaultnim modulu, ale vzdy mas moznost ctrl + shift + d si zjistit přesný název pole, pokud ti to neni jasny od pohledu... A uzivatelsky formulare myslim nema cenu rozebirat, kdyz si je muze upravit kazdej jouda ze? :)

Ad datamining co tu byl zminovanej, vyzkoušel jsem využít toho výrazu, jak jsi říkal, a nepodařilo se mi nasimulovat. Udej prosim příklad.

Proč se 10 000záznamů maže hodinu? :-) Protože se hlídá konzistence dat ... jestli ti to něco říká ;) kontroluje se, zdali neni zaznam navazany ve vztazích, případně nepovolí záznam smazat, pokud na něj něco ukazuje. Pokud si navrhl systém, kde se tohle nehlídá, gratuluji, můžeš ho smazat :)

ad grid -> proboha, nastav si počet načítanejch záznamů sám a optimálně podle sebe. Jinak tady je nejaky fail, tohle scrolování se mi taky nelíbí.

Ad dialogy -> hlásil si ty chyby?

Ad focus : zadej to jako iou požadavek, určitě ti za nějaký obnos asseco vyhoví :)

ad tiskárna - https://forum.helios.eu/green/doc/cs...u_PrintRequest - oddíl 2. -> tiskárna musí být na aplikačním serveru. -> méně stěžování na fóru -> více hledání na dokument. portálu / zavolat na hotline a bude ti veseleji :)


ad externí soubory -> ve verzi 43 došlo ke změně práce s externími soubory taktéž bych doporučil manuál

https://forum.helios.eu/green/doc/cs..._-_manu%C3%A1l

Bohužel z mojí pozice nemohu mluvit o klientele, ale obecně mohu říci že například. vodárenské společnosti s heliosem jsou v celku spokojeny.

a) ad pocet uzivatelu a blokovani, mno LCS to resila 2 roky? (Marty?) a nevyresili NIC. Za optimalizovanou rozhodne nepovazuju databazi, kde jsem schopen jako administrator dosahnout vic nez desetinasobnyho zrychleni, tomu se totiz nerika optimalizace, ale sprasena aplikace. Vubec nemluve o HW pozadavcich, pro prislusny pocet uzivatelu, mame (dle pozadavku LCS) min 100x predimezovany HW(to sem zaridil tak trochu i osobne) a stejne to jede jak kdyz se.e a maluje (na HW dle specifikace by se to nedalo provozovat, coz nam potvrdilo nekolik zakazniku, kteri naivne uverili).

b) ad prava, rad bych, ale to by to muselo fungovat (nekolikanasobna zkusenost).

c) Sorry, ale kazda normalni aplikace si bere viditelny nazev z nejaky prekladovy tabulky, a zobrazuje ho vsude a vazne chci videt, jak budu chudakum uzivatelum vysvetlovat, ze to co videj na formulari nenajdou v seznamu poli ve filtru a ze si maj nejdriv zjistovat jak ze se to ve skutecnosti jmenuje. O tom, ze to je tak jako tak bordel (uzasna vec, kdyz to neni razeny abecedne, ale podle typu, kterej je omarkovanej nejakym pidiznakem a navic v tom nejde hledat) ani nemluve.

d) ad mazani, znaji v LCS neco jako cizi klice? Podle vseho neznaji, uzasne sledovat jakym zpusobem (napr) mazou data. Konzistenci dat ma zajistovat databaze, a ne aplikace. Nemluve o tom ze mluvim o LOGu!, tedy nic, co by stalo z pohledu dat za rec + tu sou od toho transakce. A ad konzistence dat, uz se LCS naucila zaridit UNIKATNI cisla dokladu? Pokud vim, stav je jiz nekolik let takovy, ze doklady (celkem bezne) maji obcas stejna cisla. Pri nasem mnoztvi jich sem schopen najit tak 10 do mesice - opet opakovane reportovana (a zdaleka nejen nami) chyba, kterou jaksi neumi vyresit. Vubec nemluve o uzasnem systemu generovani noveho cisla dokladu pohledem do databaze na posledni existujici => pokud udelam fakturu, a nasledne ji smazu, tak dalsi faktura bude mit stejny cislo (plati obecne o vsech dokladech), fakt uzasny.

e) hlasil sem tolik chyb ktery nikdo nevyresil, ze to uz ani neresim, stejne jako vsichni ostatni admini a ne, opravdu nehodlam ani premyslet o placeni za opravy CHYB.

f) ad tiskarna, kde tam je, ze ma byt lokalni? Kdyz primontuju sitovou tak v ramci aplikacniho serveru existuje, kazda jina aplikace na ni bude tisknout. Ostatne tisk je vubec kategorie sama pro sebe, kolik ze tam je tech tlackatek, 7? A ani lidi z LCS nedokazou vysvetlit, jakej je mezi nima rozdil.

BTW: Vodarny, ty asi nemaj 20 000 polozek ve skladu co? Ta jedna co tam maj ta to opravdu nevytrhne.

Nejvic me pobavily ty plky pri prechodu z PB na NET, ze je to jen patch na odpoledne, a ze to vykonostne bude pry dokonce lepsi nez PB ... :lol: ... pripadne predstava LCS o tom, co to je tenky klient (ma to 200MB, to je fakt klientik do mobilu jak kdyz fikne) ... pripadne 3stupnova architektura (min 1/2 logiky neresi aplikacni server, ale klient + SQL scripty) a taky me bavi, jak chudak nas partner pres podporu musi bastlit do DB vsemozne triggery a updatovat natvrdo do databaze, aby zajistil pozadovanou funcionalitu.

Vysledek prechodu na NET byl ten, ze vykon spadnul zhruba 10x a bez toho co jsem v DB udelal by se to nedalo pouzivat vubec (napr takove pridani polozky na poptavku trvalo cca 2 minuty - optimalizovana databaze od LCS).

---
Jen tak jeste hodne pod carou:
Pozadavek: Potvrzeni funkcionality na SQL 2k5 (provoz na 2k)
Vyjadreni: No mi to na tom mame a funguje nam to ...
Vysledek (po testovacim prevodu): No ono je treba x, y,z, .... a to vsechno bude trvat min celej den ... a jeste to nemusi dopadnout ...
Nekolik tydnu po prevodu ostre DB: No mi sme zjistili, ze stimhle nastavenim(vyse doporucenym jako jedinym moznym) nam nefunguje KLM, bylo by lepsi, kdyby ste to prevedli zpet (naprosto nerealne).

Predpokladam ze prechod na vyssi verze bude vypadat podobne - "si to nejak prevedte, ale taky vam to nemusi fungovat"
Ocekaval bych, ze u SW za par mega dostanu jednoznacny vyjadreni ve smyslu "ano, SQL 2k5 podporujeme, funkcionalitu garantujeme a je treba nasledujicich kroku:"
Stejne jako bych ocekaval, ze dodavatel je schopen rict, zda neco bude nebo nebude fungovat v nejake konfiguraci (ze to otestuje) a ne ze rekne "no mi to tak nemame, tak nevime".

Většina problémů HeG podle mého názoru pochází z toho, že jde o aplikaci koncepčně starou. Takových systémů jsou spousty, kde nejsou žádné relace, cizí klíče... Díky bože za aspoň za indexy a constrainty! HeG aspoň používá čísla subjektu v akceptovatelným formátu, takže s rozumným fillfactorem se dají postavit slušný clusterovaný indexy - výkon jde nahoru... nevim ale co je tam v defaultu, docela bych se na to po letech zas mrknul, kam se soudruzi posunuli.

BTW tenhle thread je na první stránce výsledků googla na dotaz "Helios Green" ;D

Neposunulo se to vubec nikam, krome toho ze preklopili PB na .NET a pri ty prilezitosti zachovali vse co v PB stalo za kulovy a pribalili k tomu novy svinstvo v .NETu.

Napriklad nova featura NETu je, ze klient nemuze bezet trvale, anzto si pres noc restartujou IIS a on pak neumi reconect. Co je na tom jeste uzasnejsi, ze se neumi ani bez kecu ukoncit, navic se tvari, jako ze bezi.
Takze klasickej uzivatel prijde, vidi bezici aplikaci a klipne na poradac. Tam mu vyskoci info, ze aplikace zdechla Příloha 9000. Ovsem klient jako takovy dal bezi, s otevrenymi okny lze hybat, ale uz nereaguje na podnety tupu otevreni poradace (nijak). No a kdyz se klipne na krizek, tak se to jeste pro jistotu zepta, zda vazne ukoncit tu zdechlinu Příloha 9001. Tohle musel psat chorej mozek.

Jak uz sem nekde vejs psal, narozdil od PB prisla dalsi featura a tou je, ze v prehledech (grid) nelze zobrazit vic nez 5000 zaznamu (natvrdo). Ono se neni moc cemu divit vzhledem ke zpusobum prace.

Jop, narozdil od 41, 42+ uz nema webovy rozhrani.

Nekde cestou od 41 taky zmizla moznost pouzivat kombinovane win/user-pass autentifikaci, ted se musis rozhodnout ze bud jedno nebo druhy.

Dalsi featura (mozna sem to sem uz taky psal) - telefonni cisla. Driv to bylo proste textovy policko, ted z toho udelali vztah. Jestli si pamatujes pruser ohledne DIC a evidence DIC, tak tohle je totez, akorat ve 100x vetsim rozsahu. Uzasny kdyz chces na organizaci zmenit nakou drobnost a ono ti to nejde ulozit, protoze mas v byvalem textovem poli neco jako "pan Voprsalek 0609123456", coz je sice z pohledu dat prasarna, ale daleko vetsi je menit pole v databazi z jednoho typu na jiny.

Co se tyce DB - bez jakekoli zmeny. Stale jedina centralni tabulka, do ktere se leze i tam, kde je to naprosto zbytecne.

Nemuzu mluvit o přímém řešení, ani nevím z mého pohledu jestli vodárny sklad používají, ale pracují třeba s evidencí zařízení kde se pohybují řádově v statisících. Tak tu neplač nad 20 000.


Nevim o plcích k přechodu z pb->.net jestli to někdo sliboval tak chorý, protože migrace z pb to .net byla kapitola sama o sobě včetně všelijakých převodů reportů atd...


Pohybuju se v systemu zasilkovy sluzby, kde na skladě mame položek mnohem více než 20 000, a taktéž s výkonem problémy nějak nejsou, doporučuji rozdělit výkon na více strojů klidně méně výkonných ve farmě... nic jinyho ani nejde. A pokud máš jak říkáš spoustu logiky řešený triggerama... tak bych začal s problémem tam :-D :-D


Co se týče návodů atd na přechod na verzi 43, opět tě musím odkázat na dokumentační portál, člověče, čteš vůbec co ti píšu?

klasika indie helpdesk :)

Mejme uzivatele HeG, ktery ma cca do 50ti skladovych polozek (nemluvim o mnoztvi skladem, ale o skladovych kartach). Onen uzivatel ma 5 prodavacek - zensky co sedej za stolem a prodavaji tech par polozek stale dokola. HeG neni schopen v zadne konfiguraci uspokojit pozadavek, aby prodavacka necekala na pridani polozky vice nez 1s (rozumny maximum). Proto ma onen zakaznik extrabur aplikaci, ktera nedela nic jinyho nez se laduje objednavky do extraburt tabulek a pres noc se to presype do HeG.

Samo to sebou nese i jiste dusledky - napriklad v prubehu dne nelze zjistit aktualni stav skladu (coz zakaznikovi sice vadi, ale neni to v jeho provozu nijak podstatne). HeG to proste neni schopen ruzmne rychle zvladat, o realizaci skladovych dokladu vubec nemluve.

---
Mejme jineho uzivatele, ktery pozaduje po systemu takovou trivialni vec, jako zauctovani faktury za bezneho provozu. Prakticky nelze. Zauctovani dokladu totiz zamkne sklad, pokud je na fakture vice nez nekolik malo polozek (do 5ti rekneme) tak trva jeji zauctovani i nekolik minut a po tu dobu nemuze prakticky nikdo nic (prijemky/vydejky/poptavky ... zkratka vse co pracuje se skladem).

Proto se faktury uctuji pres noc, coz sebou nese jiste dusledky ... napriklad nemoznost provozu 24/7
O akcich typu ucetni uzaverky a podobne ani nemluve, to se samo musi delat pres vikendy.

---
Mejme tretiho zakaznika LCS, ktery ma spoustu (jednotky tisic) zamestnancu, a jeho (celkem logicky) pozadavek zni, aby zamestnanci dostali vcas vyplaty. Pokud nekde cestou k nim nastane nejaka chyba, nerealizovatelne. Vypocet vyplat trva 3 dny v kuse. Schvalne, jak dlouho bude pocitat prumerne zrucna mzdova ucetni vyplatu rucne? 5 minut?. Takze 10 ucetnich by HeG spolehlive porazilo.

---
Opravdu mam rad, kdyz nekdo plka o clusteru, ktery HeG neumi pouzivat. HeG NENI schopen provozu s rozdelovanim zateze (a podotykam, ze toto je oficielni stanovisko LCS). Podotykam taktez, ze vykon HeG je prakticky naprosto nezavisly na vykonu HW, i kdyz budu aplikaci pouzivat uplne sam, bude to tragedie. HeG zaroven neumi pouzivat ani bezpecnostni cluster. Mimochodem, mame dva aplikacni servery (pro tech cca 30 lidi pracujicich zaroven) s parametry zhruba desetinasobnymi proti pozadavku LCS. O SQL se da rict, ze pozadavky prekracuje v soucasnosti min stonasobne.

Pro neznale: HeG neumi (vubec) pracovat na DB clusteru, dost pravdepodobne (vyjadreni LCS) nebude ani fungovat pokud si koupite maximalistickou licenci SQL s moznosti rozdeleni tabulek z duvodu paralelizace dotazu. M$ SQL prozmenu tak jako tak neumi vykonostni cluster - umi pouze cluster zabezpecujici provoz pri vypadku.
HeG umi pouzivat vice aplikacnich serveru, ovsem "zatez" se rozdeluje "od kusu" = rozdelule prihlasene uzivatele, nikoli realne vygenerovanou zatez. Ovsem jelikoz aplikacni srv jako takovy nedela prakticky nic, tak je to stejne jedno.
V pripade vypadku primarniho serveru, se HeG stane nepouzitelnym - uzivatele pripojeni na sekundarni zustanou (az do restartu IIS) pripojeni, novy uzivatel se neprihlasi. V pripade vypadku sekundarniho serveru to nejspis bude kazdemu "druhemu" uzivateli hlasit chyby pri prihlasovani (nebo to opet nepujde vubec - tuhle variantu sem netestoval). Klient se totiz natvrdo pripojuje na primarni server (o existenci sekundarniho nema ani poneti).

---
Ad triggery - oficialni reseni na doporuceni LCS, min 80% jich je primo od nich (jen tak lehce sem browsal po databazi z zjistoval co ze mi to tam tak hnusne brzdi moje jednoduchy query). Duvodem je, ze to jinak udelat nelze (pry).

---
A co se tyce navodu, jsou neuplne, informace v nich stoji za starou backoru, protoze system se chova vzdy jinak, nez je tam napsano, coz potvrdi spousta jinych lidi. Dodavatele externich aplikaci (napriklad) se musi sami metodou pokus omyl ucit se systemem komunikovat (a to vcetne tech, kteri jsou oficielnimi parnety LCS), protoze co je tam napsano jednoduse neni to, co system dela. Mimochodem, prechod na 43 z ust LCS "to neni migrace, to je vazne jen patch jako kazdej jinej" ... uz sem par informaci pobral od jinych zakazniku ... (a jejich adminu).

Patche jsou vubec kapitola sama o sobe, kdyz se me takova blbost jako trebas MeGUI umi zeptat, jake komponenty chci a jake nechci aktualizovat. V pripade LCS se me nic nezepta a tak si kvuli ucetnicvi rozbiju sklad/komunikaci s externima aplikacema/... (opakovana zkusenost) ... protoze nekdo vymyslel nejakou dalsi uzasnou featuru, pripadne opravil nejakou "chybu".

BTW: Prijde vam normalni ze se doklad chova ruzne podle toho z jake strany do nej vlezete? Asi jo, kdyz to pisete. Zrovna cerstva zkusenost.

Ad MS SQL. Dovolil bych si pár maličkostí:
- failover cluster na MS SQL je teoreticky pro aplikaci zcela transparentní, protože se schovává za virtuální IP/jméno a služba clusteru si to už na nižší úrovni někam směřuje; aplikaci je buřt, co se s jeho dotazy děje, důležitý je, jestli na korektně položenej dotaz dostane korektní data.

- rozložení dat jedné tabulky do více souborů aneb partitioning - smysl to má dle mého názoru spíš pro odlití archivních dat pryč, aby pracovní datové soubory nebyly příliš velké. Partitioning kvůli paralelizaci budiž, ale to by musel být sakra HW... no ten ostatně máte ;D Takže klidně, ale viz dále - pravidla pro filegroupu a počet jader:

- spíš než partitioning bych uvažoval o větším množství souborů ve filegroupách a konkrétní tabulky (např. subjekty) bych nasměřoval do jedné filegroupy s odpovídajícím počtem souborů (počet jader>n & počet aktivních disků v poli>n), takže např. na 4jádrovým stroji s RAID5 bych udělal filegroupu FG_SUBJEKTY s třemi soubory; recreatnul subjekty CREATE lcs.subjekty ON FG_SUBJEKTY [...]

- v triggerech pokud možno nevolat ad-hoc dotazy, i když parametrizované, ale uložené procedury (cachují se pro ně execution plany a je to rychlejší, nežere to paměť)


Na hraní je toho dost...
Pošlu ti zejtra jeden dotázek, docela by mě zajímala statistika waitů nad vaší DB :)

Toreticky to transparentni je, ale nikoli pro LCS ;D, neboj se, presne na tohle sem se jich (mimo jiny) ptal. Na ruzny metody optimalizace jakbysmet, a jelikoz nejsou schopni rict ze to s tim nastavenim bude fungovat, tak to zkouset nebudu.

Pro zajimavost, jak vypada chybova hlaska pro uzivatele:

Příloha 9011

Tak to je kvalitní :-) Čekal bych aspoň něco jako "odeslat správci systému" nebo něco takovýho :-)

Tipnu si na průběh hovoru s uživatelem, kterému tohle vyskočí? (U: uživatel, A: admin)

U: Dobrý den, pracoval jsem s Heliosem a vyskočila nějaká chybová hláška
A: Jaká?
U: Taková velká, bylo tam napsáno, že se mám obrátit na správce
A: OK, co ještě se tam psalo?
U: Já nevím, ale bylo to přes půl obrazovky, nerzouměl jsem tomu a bylo tam jen tlačítko OK, tak jsem ho stiskl a ono to zmizelo...

Jop, takhle nejak to funguje, v tomhle pripade sem nastesti samo vedel co se deje, protoze sme lehce ladili srv a on holt neustoji restart printserveru, tak sem ho musel restartnout a tohle to hlasi kdyz aplikacni srv nebezi (clovek by ocekaval jednoradkovou hlasku ze se nelze pripojit k aplikacnimu serveru XYZ). Ale ve spouste jinych situaci uzivatel jednoduse neni schopen ani popsat, jak se k ty chybe dopracoval a i kdyz je a povede se stav navodit, tak stim jakozto admin muzu delat leda kulovy, protoze opravdu nevim co to dela na radku 105 ...

No abych se taky pripojil troskou do mlyna na tema hg.

Neznam cloveka ktery by byl s hg spokojen. Delam ve firme ktera mela cca 700 useru. Mel jsem tu cest pozorovat prerod z norisu na hg. Dnes si o tom myslim ze si znas tehda lcs delalo snad srandu. Pamatuju na jajich studie nasazenia dalsi tlachy ktere s slusne zplatily spolu s partnerskou firmou. Vysledek nakoupeny hw za x mio na kterem se farma stourala v nose. A client pc se ohulil tak ze skoro roztekl takze se pak zase investovalo x penez do upgrade stanic. A to jen proto ze se to temer vse narvalo na tlusteho klienta. Viva microsoft gold partner...

Dalsi usmevne tema byl prevod z pb na .net platformu. Super... vysledkem je ze dodnes slozitejsi sablony vyrabej v pb11. Takovehle nalozeni s dw jsem opravdu necekal. Clovek nevedel jestli se tomu ma smat nebo brecet. A to bylo i obdobi kdy jsem skonci s betatestovanim pro lcs. Protoze vyvijet nastroje jen aby ten jejich zazrak fungoval kdyz oni toho nejsou schopni a za dara me fakt nebavilo.

Dalsi kapitolou jsou patche a prava.. A to pomijim obodbi kdy se predelaval system prav. Po kazdem patchi se pravidelne rozesere konzistence prav. Nekteri uz nemaji co meli a jini ejhle na co tady mam to tlacitko. Na chybky jsem asseco i jejich vyznamneho partnera upozornoval nicmene uz me nebavi hledat kde to zas podelali. Dale jak mi bylo zdeleno od dodavatele oni to proste na farmach neskousej. Takze se bezne stavalo ze se to uz nerozjelo a nebo rozjelo ale s takovymi problemy ze bych se utelefonoval s usery. Takze se prohazovaly farmy mezi sebou radej. O rozdelni zateze a dalsich super vecich jako redirectovani a terminalove servery ani nehovorim.

SQL njn lidi kupte si poradne zelezo za par mio a budou dotazy trvat jen par minut ;-) Co rict vic na jejich tabulku lcs.subjekty ktera treba unas ma 19 716 280 zaznamu... takze si jedinci kteri o hg neco vedi dovedou predstavit jaky hw asi taha tu paseku ve vnitr hg.

Jako byvaly prog rikam ze se mi jezili obcas hruzou vlasy na hlave kdyz jsem do toho systemu stouchal klackem. Ale tady uz jsme u toho co od toho muzem chtit kdyz radej investuji do marketingu a nadstandartnich vztahu nez do kvality vyvojaru ci vyvoje.

Ale abych jen nenadaval kdysi jsem z povzdali videl neco cemu rikali tusim pis bezelo to na vodarnach v ostrave snad i na sme. A myslim ze az na to ze to bylo postavena na pb (ano dw je krasna vec) to nebyl uplne spatny system na ten pravek.

Vitej do klubu ;D

BTW: Vymysleli novou uzasnou featuru - oddeleny patchovani mezd. Vsemozny maily co kde je treba prekonfigurovat mi chodej takovym tempem, ze to vidim na dalsi akci migrace => 1/2 toho prestane fungovat a ta druha bude delat uplne neco jinyho nez se ceka.

BTW: V subjektech mam cca 1/2 - kolem 10M ;D.

Tak mam v prackach relativne novou instalacku HG. Neb jsem nucen neco otestovat. Mimochodem domain opravneni pro version manager ji tak nejak nefunguje. Na w2003s to napise ze sw byl uspesne nainstalovan bez hlaseni nebo tak nejak a pak plachata o tom ze ap server je nedostupny :-D typuju na prava na sdilenich. Kdysi ta instalacka aspon zarvala ze nemuze zapsat protoze... tet je jeste lepsi... docela me udivuje ze za ty roky nebyli schopni doladit instalacku serveru.

Nj, dyk ty kkti dodnes neumej nainstalovat na 64bit widle - musi se rucne editovat ODBC profil v registru (tuhle kktinu potrebujou kvuli tisku, kerej je kapitola sama o sobe).

Klient je to samy - neumej to nainstalovat tak, aby se to dalo aktualizovat bez drbani prav pod userrem.

Nejvic me dojala konfigurace "clusteru" aby se dal aktualizovat z jednoho stroje - vivat bezpecnost (je treba do site nasdilet prakticky vsechno), takze sem se na to vybod a patchuju kazdej zvlast (ono to ma i dalsi vyhody - kdyz se neco podela, tak mam jeste druhej funkcni a staci mi zmenit DNS a preflaknout konfigurak). Nebo jejich pindy ze se to da aktualizovat za chodu ... a kdyz sem se zeptal, jak za chodu zmenej strukturu DB tak cumeli jak ...

Default "bezpecna" konfigurace serveru (dle jejich wiki) je taky uzasna - RW prava pro vsechny do adresaru aplikacniho serveru ... sem to cely musel prekopat a samo predelat na https.

Hele, Michale, teď si tak vrtám v testovací DB a koukám, že subjekty nejsou definovaný jako clusterovanej index. Jen tak z legrace jsem si ho tam nadefinoval nad cislo_subjektu a select do lcs.subjekty se zkrátil na dvě třetiny původního času.

Nechceš to testnout nad nějakým větším počtem záznamů a na nějaký větší dotazy? Já mám testovací jen s 30 tisíci subjekty...

edit
před:

Kód:

---

SQL Server parse and compile time:
  CPU time = 0 ms, elapsed time = 0 ms.

(1 row(s) affected)
Table 'subjekty'. Scan count 0, logical reads 3, physical reads 3, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

 SQL Server Execution Times:
  CPU time = 0 ms,  elapsed time = 2 ms.

---

po:

Kód:

---


SQL Server parse and compile time:
  CPU time = 0 ms, elapsed time = 0 ms.

(1 row(s) affected)
Table 'subjekty'. Scan count 0, logical reads 2, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

(1 row(s) affected)

 SQL Server Execution Times:
  CPU time = 15 ms,  elapsed time = 2 ms.
SQL Server parse and compile time:
  CPU time = 0 ms, elapsed time = 1 ms.

 SQL Server Execution Times:
  CPU time = 0 ms,  elapsed time = 0 ms.

---

edit2
ty fyzický čtení v druhým případě jsou tím, že to bylo už v RAM.

Se podivej do nasi DB ... tohle tam samo uz davno mam, LCS jsou totalni trotlove - bez toho byly nektery operace i 50x pomalejsi. Dyk pri testovaci migraci sem zrusil vsechny svoje indexy a nedalo se to pouzivat - to tak ze vubec, trebas jen pridani radku na poptavku trvalo minutu.

Problem je, ze oni query generujou nejakym shitoznim generatorem, a naprosto s klidem joinujou tabulky pres textovy pole. Nektery sablony sem predelaval rucne a byly 10x+ rychlejsi (i pri tom bidnym navrhu db).

Sem pridaval celkem hromadu indexu, coz samo zvedlo velikost DB (zhruba na dvojnasobek) a ponekud (ale jeste akceptovatelne) zpomalilo inserty. Tusim ze nejaka ucetni operace se potom z nekolika hodin zkratila na radove minutu ...

Jak sem uz psal, tomu nerikam optimalizace, ale totalne zmrvena databaze. Optimalizaci se da v optimalnim pripade ziskat 10%.

Edit: Ja sem dokonce takovej dobytek, ze si dovolim v subjektech mazat ;D, oni totiz ti kreteni generuji log XML prenosu jako subjektovej a za tejden vygenerujem asi mililon zaznamu. Smazat tech milion zaznamu z HeG je tak na 14 dnu ... ;D, v DB to smaznu za vterinu.

Ono jak tak koukám nejsou clusterovaný indexy nikde, což je dost na nic - minimálně zavedením clusterovanýho indexu snížíš počet fyzických IO operací při čtení o 1, a to je při tabulce do 8 mld záznamů z 4 na 3, při <4 mil. záznamů pak z 3 na 2 !

BTW bacha na to, všespásný to není - negeneruj clusterovaný indexy nad blbejma typama sloupců. Ideální je to mít nad int / auto increment, což v případě cislo_subjektu popř. cislo_objektu nad např. lcs.sk_polozka je - sice asi aplikační logikou, ale to není v zásadě podstatný. V opačným případě dochází k page splitům v indexu a nutnosti přeorganizovat celej index při insertu hodnoty, která není na konci již existujících hodnot v klíči indexu.

Pro zajimavost, podle tech kretenu je to, ze zaznam v logu neobsahuje ZADNOU vazbu na doklad ke kterymu patri normalni ....

Citace:

---

Původně odeslal Marty

Ono jak tak koukám nejsou clusterovaný indexy nikde, což je dost na nic - minimálně zavedením clusterovanýho indexu snížíš počet fyzických IO operací při čtení o 1, a to je při tabulce do 8 mld záznamů z 4 na 3, při <4 mil. záznamů pak z 3 na 2 !

BTW bacha na to, všespásný to není - negeneruj clusterovaný indexy nad blbejma typama sloupců. Ideální je to mít nad int / auto increment, což v případě cislo_subjektu popř. cislo_objektu nad např. lcs.sk_polozka je - sice asi aplikační logikou, ale to není v zásadě podstatný. V opačným případě dochází k page splitům v indexu a nutnosti přeorganizovat celej index při insertu hodnoty, která není na konci již existujících hodnot v klíči indexu.

---

Ano, z vlastní zkušenosti souhlasím, je to obecný problém architektury tříd v Helios Green. Helios Green používá "posun do META", kdy všechny hlavičkové záznamy v jsou subjekty, tím získává datový návrh značně na flexibilitě, ale klesá také silně výkonnost databázového stroje. Pokud tabulky jako subjekty nebo sk_polozka narostou do desetimilionovych řádů, pak dochází k vzájemné blokaci uživatelů při určitých operacích, pracujícíh s větší množinou záznamů. Je vcelku jedno, jestli uživatelů je 100 nebo 5, blokuje se tabulka subjekty a treba take sk_polozka a vyrobce na to ma specialni udelatko, kterym blokovani presahujic rozumny cas odstreluje, jinak je treba restart SQL Serveru.
Řëšením by měla být dle mého názoru archivace záznamů do archivní databáze. Pro opravdu veliké projekty, kde vznikají miliony záznamů skladových pohybů relativně rychle, se myslím Helios Green nehodí, pro střední firmu ale je OK.

Zdravím, dlouho se tu nic nedělo na toto téma. Systém Helios Green se mohl za tu dobu někam posunout. Jaké máte i po těch letech zkušenosti s tímto systémem?

Co bys chtěl tak plusmínus vědět? :)