Helios Green aneb nejsprasenejsi aplikace kterou znam

[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?

[NeMeM9aA]

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 ....

[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

[xvojta]

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...

[D_a_v_i_d]

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

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

[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....

[Marty]

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

[MEluZíNa]

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...

[Jezevec]

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.

[Jezevec]

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.