Názory k článku PostgreSQL v roce 2005
-
Programátor (neregistrovaný)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 :-)) -
robo (neregistrovaný)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, -
robo (neregistrovaný)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 -
Petr Kubanek (neregistrovaný)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. -
CHe (neregistrovaný)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. -
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. -
Petr Kubanek (neregistrovaný)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..
ČLÁNKY DO MAILU