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 :-))
a nani to tak ze se musi platit pouze tehdy kdyz se chce mysql vyuzit pro soft, ktery chcui komercne prodavat? Pouziti i v komercnim prostredi pro databazove ucely je myslim free ....
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
ja bych na to sel z pohledu komplexnosti SQL. A Postgre ma implementovano prakticky vse ze standardu SQL. Mysql chybi plno veci a vnorene dotazy jsou tam taky reseny tak nejak divne .....
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.
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ší.
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