Vlákno názorů k článku PostgreSQL v roce 2005 od jjjjj - olap neni ani zdaleka vsetko to co maju...
-
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..
