Vlákno názorů k článku Setrvání na Windows může být neúnosně nákladné od huh - teda za mých krásných mladých let tohle býval...

tak to ted bude blog, no... toho nadelate :P

jestli by nebylo lepsi, kdyby root proste jen vycichnul jako ug, tohle je uz nedustojne ...

zajimalo by me zda to J. a jeji banda delaj proto, ze si mysli ze z toho neco bude, nebo jim uz jde jen o prachy (dotaz na redakci, hint hint ;-)))

(nebo ze by ta treti moznost ? ze si mysli, ze z toho neco bude, a to neco budou prachy ? ;-))))

co vadi na mssql ? prehnane drahe reseni (v pripade, ze potrebujete vice jak 5 klientu a nepotrebujete nekterou z "advanced" vlastnosti), zamcene na 1 platformu (pokud nutne nepotrebujete windoze server tak zamrzi vyhazovat dalsi penize jenom proto, aby to melo na cem bezet)

jo, mssql neni spatna zalezitost, od te doby co to M$ nakoupil od sybase na nazval to mssql to uz urazio hodne cesty, obzvlaste DTS, management a vyvojove nastroje jsou na slusny urovni, pokud clovek vyviji pod win/.net a nevadi mu co to stoji tak je to vynikajici volba.

proste pokud reseni projektu bude stejne tak nakladne ze nam to MSSQL znatelne neprodrazi, chceme se "zamknout" na klientech i serverech na windows a navic potrebujeme nektere z jeho vlastnosti (2005 bude pekne nabita novinkami, jen doufam ze budou vychytane ty otravne malickosti co mi u bety pily krev ;-), je to jasna volba, jakmile jen neco z toho neni pravda hodi se zauvazovat zda by nebylo vyhodnejsi pouzit jiny DBMS.

Jen bych dodal, ze mssql byl ve verzi 7.0 kompletne prepsan a tudiz, ze sybase v nem nezustal kamen na kameni(to jsou slova jeho vyvovare z MS)

Tak tomu never. Jedine, co tehdy MS zmenil byl parser a optimizer (ktere stejne dodelal az v MSSQL 2000) a pak take rozsireni komunikacniho protokolu TDS tak, aby nebyl kompatibilni s tim od Sybase - hlavne kvuli NEpristupu z Javy, PHP, Linuxu apodobne pres Sybasi drivery. Jadro serveru (Open Server), filozofie prace s pameti, zpusob ukladani dat - to vse zustalo nastesti stejne. Jo a taky bylo nekde po ceste pridano zamykani na urovni radku (a prislusna zmena indexu).

No nevim, taky to muze byt jeho neznalost... :-) U nas se pouziva MSSQL 2000 nad databazi o velikoste radove 10GB a problem s tim neni (a tech radku bude urcite vic nez 10k)...

neda mi to odpovedet, u nas se pouzivat MySQL 4.0.22 nad databazi o velikosti 7.7GB (86 mil zaznamu), server dela 1104 dotazu / sec a problem s tim neni. Pokud pan z firmy A ma pocit, ze experti od MS jsou jedini, kdo mu pomuzou a ma tak silnou potrebu utracet penize "za prd, kterej se jinde vali zadarmo" (konstatuji s ohledem na potreby firmy A), proc si nekoupi komercni licenci MaxDB?

S temi 10k zaznamy bych silne nesouhlasil. Nam na tom beha db o velikosti 56GB (cca 650mil zaznamu) a server i ve stadard edition to zvlada. Skoda jen, ze to stoji tak strasne prachy. Za 4GB RAM clovek zaplati neuveritelno a uz vubec nemluve o klientech. Za stejny prachy clovek dostane DB2 s daleko lepsim vykonem. MS SQL je stabilni, jednoducha zalezitost, kterou rozchodi (v ramci moznosti - vykon tomu odpovida) bezny klikac. Ani bych moc nesouhlasis s problematikou JDBC. To mi pripada take vcelaku pohodlne. No je to veci nazoru. Osobne tu lobuji jiz nejaky cas za DB2/Linux (idealne x86_64:-)), ale MSzarputilost je jen tezko prekonatelna. Dokud jista sorta lidi nevymre, pak se furt budou bastlit veci v Accessech/MS SQL. Aach jo. Ale stejne mi unika informativni hodnota tohohle clanku:-)

mno ja nevim, me argumenty typu jedna pani povidala, jestli to ma na pc ktere ma chaby hardware ci malo pameti, tak se nedivim, ale co do rychlosti a spolehlivosti si na MS SQL nemuzu stezovat, nebyt tech mizernych zaplat a zpetne nekompatibilite, ci mizernych nastroju ktere jsou dodavane se serverem tak bych byl i spokojen, ale za ty prachy jdu radeji do Firebirdu.

> BTW nějak jsem nepochopil, co vám vadí na MSSQL?

ze by cena? :))

kdyby jen cena, ale i zpetna nekompatibilita, podivne se chovajici servis packy atd.
Za tu cenu bych to cekal spis u Firebird ale u MS SQL, pricemz Firebird je naprosto uzasny databazovy server, jeho vyvoj je uz dost daleko, spolehlivost, hardwarova narocnost atd je daleko pred MS SQL, mno sikovne jsou i UDF. Asi bych ho nenasadil tak kde je potreba tisice transakci denne ale jinak, pro stredne velkou firmu velky kvalitni reseni.

Aldik

Přesně tak! Proč to nejde provozovat na normálních Windowsech mi dost uniká, žádné vazby na věci, co jsou až v serveru to nemá.

ze by proto, aby nekdo prodal sve predrazene "serverove" reseni ?

marketing je veskery zlo. lidi z QSSL (ti co pisou QNX) maji skvely programatory, perfektni os, a jedinej duvo proc neni jeste pouzivanejsi je, ze ta banda kokotu (pozvolna promenovana, ale furt to samy, kolektivni IQ 0 a pouze nabiflovano "jak maj prodavat" absolutne nechapajic ze na jejich sektoru trhu by to chtelo jinej pristup) z marketingu jim porad ubira perspektivni zakazniky a stavajicim komplikuje zivot.

MSSQL je super. nejlepe s jdbc. 2 hodiny mi trval vyvoj knihovny. 4 hodiny minimalne ted reseni chyby v s microsoftim jdbc ovladacem k MSSQL. nechapu proc jsou windows neunosne nakladne.
vzdyt pripojeni k internetu se zkratilo z 3 dnu na 15 minut.
2400 hodin bylo usetreno diky centralizovane sprave serveru.
a diky windows 2003 server muzete ziskat nove jmeno.
goldenfish

takze celkove 6 hodin ztraty casu. jeste dovest novejsi versi javy k zakaznikovi.
ResultSet.getString() poradne po nejakem servispacku nechodi.
uz me ty betaverse microsoftu toci.
gf

napodobne. dopisoval jsem nove rozhrani (asp.net) nad starsim systemem bezicim nad FoxPro (prepsat cely by byla sebevrazda, zrojaky nekomentovany, nazvy promennejch v prumeru 1.75 pismene, des. nastesti 90% uzivatelu nepotrebovala 90% funkcnosti ...), a po 2 dnech prace se nejakym zpusobem vysralo db provider (OleDB.NET/Jet 4.0, pouze pro dbase). reinstal prinesl dalsi den prace, po kterem to slo dolu zase. po kompletnim prepsani datovy vrstvy tak, aby pouzivala ODBC (kupodivu i kdyz dbase@oledb/jet nejelo, dbase@odbc ) se tato vyrala take (unknown error, stejne jako oledb). nu coz, rekl jsem si, prepsal to v php (to na stejny masine nemelo problemy, a jelikoz neocekavam ze nekdo bude kazdej tejden reinstalovat produkcni server kvuli nefungujici datove vrstve), a nejen ze to slapalo, ale dokonce se mi to k mymu vlastnimu prekvapeni psalo i lip a rychlejc. sice zadny objektove orientovany orgie jako s .net, ale hlavne ze to jede.

a protoze jsem nedavnou usoudil ze alespon pro me linux desktop je vic nez pripravenej (po vzoru trapnych clanku "je linux pripraven na desktop ?"), tak jakmile se mi podari rozjet naseho po*ranyho uzavrenyho (pro ty co radi kdyz se to furt omila tak "proprietarniho", ale v cestine mi to uz leze krkekm jak tim kazdej kolem sebe mava jako krizem proti upirum) klienta pro vzdalenou zpravu pod wine, jdou windoze z disku, a psat pro ne soft uz jen ve stavu nejvyssi nouze ...