Vlákno názorů k článku Je celý český Internet na pokraji krachu? od Vaclav Kabat - po vlastni zkusenosti s firmou, ktera sice nedelala...

No pokud uz od zacatku jste rozhodnut dluh nesplacet, pak souhlasim. Jinak splacet dluhy je neprijemne.
Je jen malo uspesnych projektu, na kterych se da zbohatnout. Me by stacilo, kdyby se zaplatil provoz webu a muj.

> Me by stacilo, kdyby se zaplatil
> provoz webu a muj.

Mozna by stalo za to mit korektni html (v indexu na abtour.cz HEAD chybi uvozovky) ;-) Jen tak na okraj. Trebas to nejakeho zakaznika otravi a nenapadne se podivat do zdroje a studovat co je blbe.

Pravda ! Triviality ale ja neimplementuju, programuji kod a vytvarim analyzu struktury dat na SQL serveru.

Mate pravdu v tom, ze vetsine normalnich aplikaci staci bohate MySQL, zalezi jen na dobrem napadu. Ja jsem popisoval stav na www.pocitadlo.org , ktere uz davno neexistuje, protoze pro normalni chod tato aplikace potrebovala:
- computer hosting za 5000kc/mes
- vykony SQL server s transakcemi, uloz. proc a trigry. Nejvhodnejsi se zda MS SQL2000 a WIN 2000 server = 100 000Kc velmi priblizne
- postovni server
- vlastni HW v cene cca 100 000Kc ( nic moc )
- vyvoj aplikace do 2mes = 60 000Kc nakladu na programatora, pokud neji jednou dene suchy chleba z vodou

to se za babku poridit neda.

vykony SQL server s transakcemi, uloz. proc a trigry. Nejvhodnejsi se zda MS SQL2000 a WIN 2000 server = 100 000Kc velmi priblizne

To je ovsem subjektivni nazor, se kterym ja nemohu "jen-tak" souhlasit. Mozna pravdu mate - nevim presne, co melo "pocitadlo.org" presne nabizet, ale za bernou minci to rozhodne vzit nehodlam. Uz jen tvrzeni, ze na nejakou aplikaci nutne potrebujete stored procedury a triggery vas jako odbornika schopneho rozumne odborne posoudit tyto veci ponekud diskvalifikuje. Je opravdu jen velice malo (pokud vubec nejake) uloh, ktere by bez techto prostredku nesly vyrobit. Ano, je pravda, ze s pokud mate mene schopne prostredky, musite mit schopnejsiho programatora (zatimco mene schopny si praci s databazi bez sotred procedur nedokaze vubec predstavit), takze je otazka, jestli a kolik byste nakonec usetril, kazdopadne, vas vypocet je podezrely. Tedy, ledaze jste chtel poukazat na to, ze uplne bez penez to nepujde - s tim se souhlasit da.

Skutecne jen velmi malo aplikaci potrebuje tyto prostredky, ale napsal jsem aplikaci pro pocitani pristupu na www stranky typu TOPLIST, nebo moje historicke www.pocitadlo.cz Tam se bez ulozenych procedur da jen tezko obejit. V tech bylo nutne pouzit transakce. Nevidim duvod, proc by me melo pouzivani techto prostredku jakymkoliv zpusobem diskvalifikovat. Byla to proste nutnost z duvodu rychlosti zpracovani. Podivejte se na ruzna pocitadla na nasem internetu a zjistite, ze jen malo ktere je vzdy maximalne rychle. Pokud jsou mene schopni analytici, resi se toto hrubou silou a koupi se jeste vykonejsi pocitac, misto toho, aby se maximalne vyuzil dostupny soft. O podobnych tezkostech by Vam mohl povypravet jeden z autoru Mr.Linxe - M. Hlavicka.

Nerekl jsem "pouzivani techto prostredku", ale "trvani na jejich pouzivani" - zapocital jste kvuli nim do svych "minimalnich" nakladu pomerne drahy kus software - a ja chtel poukazat na to, ze zapocitanych 100000 na SQL server s OS nelze povazovat za nevyhnutelnou investici.

Co se tyce "hrube sily" - pokud zakoupeny pocitac bude (kvuli potrebe vyssiho vykonu) o 30000 drazsi a schopnejsi programator dostane o 15000 Kc mesicne vice (myslim, ze jste pocital s dvema mesici prace), zato se ale obejdete bez onoho draheho komercniho SQL serveru na komercnim OS, a tedy usetrite tech 100000Kc, pak jste stale celkove usetril 40000Kc.

Me prispevky nesmeruji k hadani se o korunu - pouze jsem konstatoval, ze bez stored procedur a triggeru se da obejit prakticky vzdy, transakce (o jejichz nezbytnosti se bez presne znalosti provadenych operaci bavit nemohu, proto je za nezbytne budu povazovat) jsou dostupne uz i na lacinejsich (pripadne primo zdarma) SQL serverech, ktere bezi na lacinejsich (nekdy take primo zdarma) OS - a ten chybejici vykon (souhlasim, ze obejit se bez stored procedur znamena trochu mene vykonou aplikaci) dozenete skutecne silnejsim hardwarem, coz - a to si troufam vazne tvrdit, vas prijde na mene nez onech 100000Kc. Nenapadam ani neobhajuji zadny konkretni SQL server ani OS - jen mam dojem, ze uvedeny vypocet obsahuje urcitou cast penez predeterminovanych pro "pohodli programatora" a ohledy na jeho drivejsi zkusenosti a znalosti - a nelze tedy tvrdit, ze prezentuje minimalni naklady nutne na rozjezd a provoz podobne aktivity - ty naklady, IMHO mohou byt nizsi. Proste, vas vypocet na me pusobi dojmem "vybral jsem si programatora a ten si vybral prostredky, ktere umi pouzivat" nikoli dojmem "hledam nejlacinejsi kvalitni reseni daneho problemu" - a k tomu hledam programatora, ktery nalezene reseni dokaze realizovat, a tedy, ktery dokaze (takrka) stejnych vysledku dosahnout lacinejsimi prostredky (a zbytek dohonime silnejsim hardwarem). Nerikam, ze nakonec nemate pravdu - to nelze zjistit bez toho, ze obdobnou aplikaci nalezneme napsanou nad lacinejsi (treba nekomercni) SQL server - jen to na me mas vypocet, o tom, ze cosi lepe "nejde" nepusobi duveryhodne, nezda se mi korektni a proto jsem to sem napsal.

Asi vas zklamu, TOPlist bezi na mySQL. Naopak, byl prepsan z MS SQL kvuli vysokym narokum na hardware . Prave proto, ze nejvetsi cast provozu tvori jednoduche inserty, odpada nutnost stored procedur a uz vubec triggeru apod.
A tech prumernych 25 milionu dotazu do databaze denne (prumer za posledni mesic) neni zrovna mizive cislo. Ale je pravda, ze mySQL uslo behem poslednich verzi znacny kus cesty kupredu (napr. transakce mozne jsou).

Jedna poznamka k te uvadene cene - jen licence "per processor" na MSSQL 2000, kterou pro webove aplikace potrebujete, stoji bratru 190 tis, takze je to mnohem vic. A druha poznamka - pokud se tyka pouzivani triggeru a stored procedures - samozrejme, ze na amaterske urovni se muzete spolehnout na to, ze si ohlidate referencni integritu ze skriptu, ze neudelate preklep pri opakovanem komplikovanem vytvareni SQL dotazu ve skriptu, ze vam "aplikace neklekne" i pri velkem poctu soucasnych dotazu, ze vam webserver nikdo nehackne, atd. - skoro vsechny veci muzete "udelat nejak jinak"... - ale u jakekoliv aplikace, kde jen trochu zavisi na tom, jestli je DB bezpecna, rychla a konzistentni se bez triggeru, ulozenych procedur a transakci neobejdete. A pokud chcete optimalizovat vykon a ne si porad kupovat lepsi zelezo, jsou stored procedures k tomuto ucelu idealni cesta. A to ani nemluvim o nesmirne redukci bezpecnostnich rizik a rizik neodchycenych chyb pokud pracujete dusledne s ulozenymi procedurami i na urovni pristupovych prav uzivatelu prislusneho SQL serveru apod. Proste - profesionalni business aplikace se bez poradneho DB serveru neobejde, a to porad jeste MySQL neni - i kdyz, jak jsem slysel, dneska uz tam maji i transakce, uvidime... V puvodni podobe je kazdopadne uplne bezva na aplikace s drasticky prevladajicimi ctecimi operacemi (napr. Lupa, XChat), ale pokud se to vyrovna a dochazi nejenom k castym selectum a insertum (napr. XChat), ale i k updatum a deletum ve znacne mire, nemuzete se bez transakci a ostatnich features na nic spolehnout a tezko tam MySQL nasadite - pokud tedy nepatrite mezi sebevrahy, coz, pokud je mi znamo, nepatrite ;-))))))...

No, docela byste se divil jake vsechny veci jsem uz na MySQL provozovat videl, nebo dokonce programoval - nejspis byste, mozna, zmenil i nazor na to, jak dalece patrim mezi sebevrahy.

Samozrejme, ze profesionalni bussiness aplikace, navic silne zatizena, navic s prevazujicimi zmenami dat neni aplikace vhodna na MySQL, jenze, i to ma sve "ale". Jen vyjimecne se da ocekavat, ze na aplikaci budou kladeny takto vysoke pozadavky v okamziku jejiho uvedeni a v kratne dobe "po porodu". A pozdeji, tedy pokud se nejedna o dlouhodobe ztratovy projekt, uz zase budou k dispozici potrebne penize. Tato debata vysla z toho, jestli se da na Internetu i u pomerne velkych projektu zacinat "s petnikem". Ja se domnivam, ze da, a nesouhlasil jsem s panem, ktery pocital hned to zacatku projektu drahy komercni software (to se navic skutecne domnivam, ze na pocitadlo stezi potrebuje transakce, a nejspis ani ty ne, ale skoro urcite nepotrebuje nic jineho). Celkove sice neusetrite - do daneho projektu je proste potreba narvat prislusne penzum penez - ale mate pomerne sirokou volnost v tom, jestli je tam narvete hned, nebo jestli zacnete opravdu skoro s petnikem a penize tam narvete pozdeji (pozdeji, pravda, to znamena ze jich budete potrebovat nejspis trochu vice nez hned, ale zase vam budou stacit az pozdeji). Videl jsem MySQL nasazene i ve finacni instituci (dnes je tam jiz SYBASE - i se stored procedurami), vim o elektronickem obchodu, kde pres jejich MySQL protece plateb za hezkych par milionu korun rocne (jeste stale tam je a stale ma jeste transakce zajistene na aplikacni urovni - ale ono zas neni az tak moc zatizene nebo nebezpecne aby se to vyplatio predelavat), Postgress pouzival i nejmene jeden z ISP (dnes tam tusim maji Oracle). Mozna existuji start-up projekty, ktere opravdu vyzaduji nakup jen software za stovku tisic - ale ja to jsem ochoten povazovat za ojedinele vyjimky - a nastava to spise u projektu toho typu, ze se chystate prodavat primo onen software a ne jen sluzby, pro ktere jste ho vyvinul. Vetsina projektu, a dokonce i takovych, ktere aspiruji stati se velkymi, serioznimi a bezpecnostne-paranoidnimi se na svem startu obejde bez ohromnych investic. A vykon je opravdu v mnoha pripadech nejlacinejsi honit "hrubou silou" - teprve od urcite (a pomerne znacne) velikosti potrebneho vykonu zacina byt efektivnejsi "ladit aplikaci" (samozrejme, uz pri puvodnim navrhu je velice rozumne pocitat s tim, ze jednou bude nutne ladit vykon, ze se mozna jednou bude porotvat na jiny SQL server a pod., ale nemusi to tam vse byt od sameho pocatku). Bezpecnostni problemy, integritni problemy a jine problemy - to vsechno jsou rizika, ktera jsou pochopitelne na "nehodnem" SQL serveru vetsi nez na "hodnem" - ale obvykle jsou stale dostatecne mala, aby se je vyplatilo, v porovnani s cenou "hodneho" SQL serveru riskovat. A v naproste vetsine pripadu se da zacit, a v nemalo pripadech i prorazit s par korunami do zacatku. Znam prilis mnoho takovych projektu abych uveril jednomu vypoctu, ktery tvrdi, ze bez hromady penez se nema smysl ani pokouset ...

:-))) Dobre, vzdavam se, do vasi mozna sebevrazedne duse Vam nevidim :-))))))). Jinak docela souhlasim s temi rozjezdy za petnik a s tim, ze pokud prodavate sluzbu a ne soft, tak se na to divate jinak. Je to potom taky o narocich na to naprogramovani funkci, ktere by vam server poskytl "zadarmo" - resp. pokud zaplatite tu licenci. No, ale provozovat nejakou financni aplikaci bez transakci, to uz myslim vazne vyzaduje pevnejsi nervy i viru... ;-)))

Ona neni bez transakci - jen ty transakce nejsou na urovni databazoveho engine. V zasade to, co dela databazovy engine dokazete udelat i na aplikacni urovni - samozrejme, za cenu vykonu, a je to prace navic, a je nutne jednat opatrne, ale jde to. Ostatne, rikal jsem, ze lacinejsi software se obvykle projevi na zdrazeni prace programatora a zvysi se i cena hardware - otazka je, jake bude celkove saldo. Chran buh tvrdit, ze je to optimalni z hlediska bezpecnosti nebo vykonu - bavili jsme se o tom, co je je mozne za minimum penez. A dokonce, i kdyby to bylo uplne bez transakci - zalezi na tom, jak velka je prumerna operace, jak casto operace, ktere by jinak transakce vyzadovaly, probihaji - a jaka je tedy celkove na penezni ztratu prepocitane riziko z toho, ze nejaka operace bude provedena "jen napul". To predpokladam, ze celkovy databazovy model mate navrzen tak, ze jste schopen inkonzistenci, alespon off-line zjistit a tedy ji opravit, byt' treba dodatecne - a pak je to financni uvaha, zda se mi investice do software s transakcemi vyplati vzhledem k rizikum techto ztrat. Pochopitelne, mit to bez transakci uplne a navic tak, ze nejsem schopen integritu overit ani off-line, to je skutecna sebevrazda, a navic je to velice spatna vizitka programatora takove aplikace. Ostatne, paranoidni programator by nikdy nemel plne verit zadnemu databazovemu engine, zadnemu OS a zadnym knihovnam - navrhnout databazovy model a obsluhujici aplikaci tak, ze integritu dat a operaci je mozne (staci off-line) overit bez spolehani se na spravnou funkci engine je, myslim, znakem dobreho programatora. Takze, ani transakce nepovazuji za zaruku nesebevrazedneho systemu ...

Urcite zavisi na konkretnim projektu, takhle se dohadovat nema prilis smysl ;-)))... Naprogramovat a odladit plnohodnotny transakcni engine realizovany pomoci nejakeho transakcniho logu vcetne stupnu izolace a podobnych vychytavek je podle mne urcite drazsi, nezli si ho nakoupit - urcite zalezi, s cim se kdo spokoji. Kdyz ale implementujete transakce bez transakcniho logu (asi nejjednodussi cesta, se kterou mam trosicku zkusenosti), musite se spolehnout na to, ze se vam engine uprostred potvrzovani transakce proste nevytuhne - coz je nekdy asi trochu problem... Ale to uz jsou implementacni detaily, hahaha... A pokud se tyka te moznosti overit na nejake DB ze je konzistentni ci neni, neni to az zase takovy problem udelat veci tak, aby se zjistilo, ze nekonzistentni je (i kdyz tim asi narusite duslednou normalizaci entit), jako spis rozhodnout co si s tou nekonzistenci pocit, kdyz na ni prijdete... Nutne je urcite casto zalohovat ;-))))). "Hodne" databaze maji taky jinou prijemnou vlastnost - po havarii se vam "samy" zrestauruji a nebo je mozne je taky zrestaurovat ze zalohy a pak aplikovat transakcni log (samozrejme pokud ho mate) az po dobu tesne pred havarii ci operaci, kterou chcete vratit... :-))) Ale myslim, ze oba vime, o cem to je - proste o primerenosti technologie k faktorum jako jsou timing, budget, funkcnost a zatizeni systemu a zdroje potrebne pro realizaci... :-)))))

Tak, tak. A proto jsou jakakoliv prohlaseni typu "pod 100000Kc nejde rozumny projekt rozjet" podezrele a neduveryhodne ...

Proč jste platil 5.000 Kč/hosting? To jste měsíčně přenesl 200 GB dat? Panejo, to muselo být počítadlo. A na čem takové počítadlo vydělává? Jaký byl byznysplán?

Martine ja ti nevim :-) Musi mit vsechno byznysplan? Treba PinkNET byznysplan nema a nijak extremne mu to v cinnosti nevadi :-))))

Mno, tady nekdo rikal, ze nejde delat byznys bez velkej nakladu. Ja tvrdim, ze kdyz ma mit byznys naklady, pak se od nej museji ocekavat zisky. Pinknet ma IMO byznysplan jasne danej: mit weby zadarmo, sehnat na ne konektivitu a hardware a obsah dat dohromady za svy. To je podle myho byznysplan a docela dobre funguje. Jakej byznysplan ma pocitadlo.org, to vazne netusim.

vykony SQL server s transakcemi, uloz. proc a trigry. Nejvhodnejsi se zda MS SQL2000 a WIN 2000 server = 100 000Kc velmi priblizne

Pokud nebudete trvat na tom, že to musí být MS SQL (to je snad nějaká epidemie, poslední dobou na takový požadavek narážím nezdravě často :-)), dá se to pořídit i levněji. Asi tak o 100000 Kč.