Názory k článku
PostgreSQL v roce 2005

Viete mi niekto odpovedat, ako je na tom postgreSQL s multi-master replikaciou. Zatial je tato volba dostupna cez PGCluster, ale pokial si pamatam boli plany priamo zaclenit multi-master uz to 8.x verzie. Bude to zaclenene do 8.x rady ?

Z nekomercnich variant bude k dispozici Slony II, ktere se ale pravdepodobne integrovat s backendem nebude. Nezachytil jsem, ze by se tomu nekdo intenzivne venoval, takze bych nic v pristim roce necekal.

Dobrý den,
ve firmě používáme Microsoft SQL a já uvažuji o vytvoření verze našeho systému pro nějakou open source databázi, zatím experimentálně. Prosím Vás o radu:
1. Kterou z open source databází mi doporučíte?
2. Pracujeme s většími objemy dat. Rád bych tedy věděl jak dobře zvládají open source databáze optimalizaci dotazů, poradí si i s vnořenými sql dotazy?
3. Existují nástroje pro import/export dat z MS SQL?
4. Existují ovladače pro Microsoft .NET?

Ja PostgreSQL :-). Ale je to klasické flame. Na vsechny Vase otazky se da rici ano pro vsechny vyssi verze PostgreSQL, MySQL a Firebirdu. Pokud pouzivate ulozene procedury pak bych Vam klidne doporucil MySQL5, kdy je zpusob prace s SP SQL serveru relativne blizky. Jenomze MySQL5 je jeste trochu nestabilni a SP jsou tak na urovni MSSQL6.5 - funkcni ale pomale.

Takze abych se vyhnul flame, dohledejte si 20% nejcastejsich dotazu, 20% nejpomalejsich dotazu, dumpnete data, prevedte si je do vsech tri databazi a udelejte si vlastni testy. Dejme tomu, ze prijdete o tri dny, ale budete mit jistotu, ze jste se rozhodl spravne (mozna :-))

Děkuji za pohotovou a užitečnou odpověd!

Nie som si celkom isty ako je to s licenciou MySQL. Ak chcu portovat svoj komercny soft, tak asi musia zaplatit za MySQL? Nie?

ne, je to tak, ze musite zaplatit, nebo vydat SW pod GNU GPL. pokud nechcete platit, je tam par vyjimek (PHP, nezavislost na DB, ...), ale v podstate musite zaplatit vzdycky

zde asi bylo míněno ne prodej komerčního softu založeného na MySQL, ale použití MYSQL interně ke komerčním účelům

Ano je to v podstatě tak. Přesněji: MySQL může být provozován buď GPL, nebo s komerční licencí.

Minulý týden jsem zrovna zkoušel portovat jednu svojí aplikaci z MS SQL na PostgreSQL.
Ovladač PostgeSQL pro .NET existuje, současná verze je 0.7.1 a přestože je tato verze označena jako Production/Stable, je nepoužitelná. Vůbec není implementována např. funkce FillSchema od DataAdapteru. S ODBC je to taky dost bída. FillSchema díky bugum zase nefunguje tak jak má:
Nepozná, zda sloupec může být NULL.
S unicode verzí ODBC driveru je DataColumn.MaxLenght u varchar sloupců nastaveno na polovinu skutečné hodnoty.
Pak tam byli ještě další cca dva problémy, které už si nepamatuju.

OleDb už jsem nezkoušel a vrátil se k MS SQL serveru.

Zkuste přeci jen o něco novější verzi ovladače:
http://pgfoundry.org/frs/?group_id=1000140

Pro normální práci je .NET driver v pohodě. Podpora schémat se nechává na konec, jelikož si můžete schéma přečíst std. dotazem do informačního schématu, a nikoho ze zucastnenych to nijak moc nepalilo by to resil. Stejně tak ODBC (zatim Level2) a OleDB driver. Pomoci ODBC jsem bezproblemu linkoval PostgreSQL tabulky do Accessu. Pokud narazite na bug, tak jej reportujte. Mate tim podstatne vetsi sanci, ze Vam Vas problem nekdo pomuze vyresit.

Pokud Vám nevyhovují o.s. drivery můžete použít komerční. Předpokládám, že budou dotaženější.

http://uda.openlinksw.com/ je tam i 30 denni trial
http://www.openaccesssoftware.com/

P.S. netvrdim, ze nemuzete narazit. Ale je to potreba vyzkouset. Napriklad hodne obtizne budete portovat aplikaci, ktera pouziva multirecordsety, aktualizovane kurzory,

No zrovna metoda DataAdapter.FillSchema / DataTableReader.GetSchemaTable mi prijde tak zakladni, ze jsem jeji absenci absolutne neocekaval. Kdyz chci nechat uzivatele editovat nejaky policko v databazi, tak proste potrebuju vedet kolik znaku ten varchar sloupec ma a jestli kdyz uzivatel policko nevyplni, se ma do databaze zapsat null nebo ''.
Kdyby aspon ta metoda vyhodila NotImplementedException s nejakou hlaskou, jak to obejit. Ale ona (protoze uplne chybi a vola se metoda predka) skonci s nejakou nic nerikajici chybou a az reflectorem a ze zdrojaku jsem zjistil v cem je problem. Tohle je lame.

Schema si sice ze systemovych tabulek precist muzu, ale je to dalsi komplikace v kodu aplikace, ktera tam byt nemusi. I kdyz ted, kdyz nad tim premyslim, by to zas tak hrozny nebylo.

ODBC driver od OpenLinku jsem zkousel a na zadny problemy jsem nenarazil, ale 30 denni trial je mi na dve veci a ty ceny ($99/client) mi prijdou dost vyhroceny.

Tu aplikaci kterou pisu bych chtel mit za mesic hotovou. Ty problemy v .NET i v ODBC driveru jsou sice celkem jednoduse opravitelny/resitelny, ale vzhledem k tomu na kolik jsem jich narazil behem tak kratky doby, jsem v ty drivery uplne ztratil duveru. Nechci riskovat, ze to kuli dalsim bugum budu psat o mesic dyl nebo ze na dalsi problem narazim az v ostrym provozu, kde kazda hodina vypadku stoji x tisic.

P.S. 2 ty bugy v ODBC uz jsem reportoval to Ludek Finstrle, ty zbyly dva napisu na pgfoundry

Jo, tomu rozumim. Jenomze diky tomu, ze se dela neco ne tak uplne obvykleho, co generuje trochu zvlastni pozadavky se to muze pohnout dopredu. A je to open source. Jestli natolik rozumis .NETu, tak to oprav , dopis. 100% budou nadseny

olap neni ani zdaleka vsetko to co maju poriadne DB a free DB budu este velmi dlho mat co robit aby sa dostali na uroven nejakeho oraclu

Hm, muzu se zeptat napriklad co? Fulltext search ktery nikdo, ani od Oraclu, neumi rozchodit? Drahe konzultatnty, kteri nevedi o cem mluvi, jelikoz je k tomu ustredi nevyskolilo?

Pouzival jsem a vyvyjel jak v Oraclu, tak v PostgreSQL, PostgreSQL me bohate staci a vyhovuje. Naopak, bez nekterych "vlastnosti" Oraclu se velmi rad obejdu.

Nebo takhle - PostgreSQL bych si nedovolil nasadit na aplikaci, kde jde o hodne (lidske zivoty, velke penize - banky, rizeni letoveho provozu,..). PostgreSQL bych si troufnul nasadit vsude jinde.

napriklad XML, lepsie a prehladnejsie triggre a pod.

XML prosim. Tady ma PostgreSQL skluz. Ale triggery, tak ty jsou nemlich stejny :-).

XML je fajn ako prostriedok na vymenu dat v heterogennom prostredi, ale naco ho nasilu pchat vsade? Aby som sa mohol pochvalit ze mam aplikaciu kde nikto nescita dve cisla inak nez zaslanim XML spravy?

A ak predsa vznikne realna potreba, napisanie si vseobecneho transformatoru recordsetu na XML pripadne naopak dotazu v nejakom internom normalizovnom tvare na SQL query a tieto si potom specializovat moze byt pohodlnejsie nez boj s tzv. "nativnou XML podporou".

Prave ze v tom heterogennim prostredi potrebujete XML ukladat, nacitat, dohledavat. Treba jen proto, abyste logoval komunikaci. Pri std. zpusobu ukladani ma XML relativne velkou rezii. V PostgreSQL se to nijak moc neresilo, bo PostgreSQL interne komprimuje vsechny texty delsi 2KB.

Uz ted existuje patch pro castecnou SQL/XML podporu (generovani XML). Vim, ze v Rusku pripravuji nativni datovy typ podporovany GiST indexem. Podpora XML jako je v SQL2005, Oraclu 10 by se mi urcite libila. Nicmene, alespon v PostgreSQL to neni na poradu dne.

Je mi jedno, jak tomu, kdo rika. Uvedu priklad. Protokol vymeny prenosu telefonnich cisel mezi operatory vam prikazuje archivovat veskerou komunikaci mezi operatory po dobu tri let. Komunikace celkem logicky probiha v XML nad SOAP. Pokud mate databazi podporujici XML, tak si usetrite furu prace na aplikacni urovni. Pokud ne, tak si to holt napisete sam - nedeje se nic tragickeho. A taky mam rad XML. Nejvetsi problem XML je, ze neexistuje rozsirena norma pro binary XML.

Bylo by pitomosti redukovat SQL databazi na archiv XML dokumentu, podpora XML se hodi. Kolikrat iterujete nad dotazem, abyste vygenerovali prostoduche HTML nebo XML. S SQL/XML to vyresite jednim dotazem, ktery je o hodne citelnejsi a provede se 10x rychleji nez v Perlu, Pythonu, Phpku.

Pokud je nejaky system schopny generovat XML, a cist jej, tak je pro mne dal, nez system, ktery pro vymenu dat pouziva plain text, a to proto, ze o dost snizuje pravdepodobnost chyb, snaz se delaji zmeny, atd. Takze, kde muzu, tam prosazuju XML. Usetril jsem si furu prace, a jeste jsem se nespalil. XML knihovny uz jsou vsude.

Souhlasim s poslednim odstavcem. Plain text je pro vymenu dat nevhodny a temer vzdy je jednodussi pouzit XML nez vymyslet a ladit vlastni superprurazny format. Na druhou stranu, dokud nebude rozsirene, kvalitni a odladene binary XML, bude spousta situaci kde je nativni binarni format vhodnejsi.

na binarne data sa pouziva napr. base64

No prave :-).

base64 NENI vhodny format pro vymenu binarnich dat. Pouziva se jen na mistech, kde je zoufale zapotrebi vejit se s binarnimi daty do 7bitoveho ASCII. Jinak je strasne neefektivni a primy pristup na i-ty znak je v base64encodovanych datech zbytecne slozity.

Krome toho binarni XML neni jen o datech, je to i o usetreni koncoveho tagu a o primem pristupu k polozkam.

me toho zase az moc chybi v "komercnich" databazich :-)
znam sybase a oracle - ten je kapitola sama pro sebe.
kdyby aspon byla slusna dokumentace - tady by se od postgresql mohli ucit.

Souhlasim. A navic system komunikace Oraclu s uzivateli. Nasel jsem chybu v dokumentaci k JDBC - ma se pouzivat setPrivateTrace, ne setTrace, jelikoz setTrace je private - tu si zvenci nezavolate). Po cca 2 hodinach hledani na koho tuhle chybu poslat (budto zavolejte nasemu konzultantu nebo nam poslete fax..ale musite byt predplatitely, jinak se s vami nehodlame bavit) jsem to vzdal, takze chyba je tam zrejme dodnes.

V Postgresu jsem zjistil, ze dokumentace u ECPG k tomu, jak se predavaji typy, se vubec nezminuje o predavani data (jako cas+datum) a textu. Na datum jsem nasledne nasel priklad ve zdrojakach (test ECPG..), kliknul jsem dole na link, popsal problem, a druhy den prisla odpoved, ze to do dokumentace zabuduji.

Zda se mi, ze v dokumentaci k Oraclu proste chyby nejsou, a i kdyby byly, uzivatele je nemaji co hlasit, ty si najdeme sami a basta. Tenhle system me pripomina blazinec, ktery vladl v CSR..