Dotaz: Datový typ varchar - univerzální podporované všemi DB

[hispik]

Dobrý den. Snažím se postavit aplikaci tak, aby mohla fungovat se všemi běžně používanými relačními databázemi - konkrétně mysql, postgresql, firebird, oracle, sqlite, mssql. Proto se snažím najít takové datové typy, které podporují pokud možno podobně všechny tyto databáze. Myslím, že nebudu mít problém s INTem, datem a časem, ale problém by mohl vzniknout s textovým datovým typem. Zatím to stavím nad mysql (protože toho podporuje relativně málo a dobře se to upravuje pro ostatní rdbms) a tam je VARCHAR podle collation case sensitive i insensitive, v postgresql je standardně jen CS (ale dá se přidat i CI), u ostatních RDBMS jsem trochu zmaten (i z manuálů). Netušíte někdo jak jsou na tom ostatní databázové stroje a na jaké další omezení bych si měl dávat pozor? Mým cílem je u VARCHARU podpora utf8 a nějaké univerzální řazení a porovnávání - univerzálním myslím, že všechny musí toto podporovat stejně - je mi jedno jestli CS nebo CI, ale stejně. Na co bych to měl normalizovat?

---

---

Odpovědi

[Kit]

Hledání univerzálního řešení je cestou do pekel. Každá databáze má jiné výhody a používáním standardu ANSI SQL se tyto výhody do jisté míry stírají. Je možné nadstandardní záležitosti omezit, ale úplně se jich zbavovat by byla škoda.

V ANSI je NVARCHAR(n).

[hispik]

No a co to case sensitivity?

[okbob]

MSSQL nepodporuje utf8 - pro podporu UTF musite pouzit nvarchar, ktery zase neni podporovan v PostgreSQL.

Pristup, ktery jste zvolil, neni uplne nejstastnejsi. Rozumnejsi je pouzit treba sve jednoduche API, kterym obalite db operace, a uvnitr ktereho rozdily mezi jednotlivymi db skryjete.

[l0gik]

A SQL skripty na vytvoření db generujte pomocí PHP. Takové věci jako typ varchar pak vyřešíte pomocí jednoduchýho konfiguráku...

[hispik]

Svoje API mám. Mě jde jen o to, aby fungovaly stejně základní operace nad daty tj. řazení, porovnávání, vyhledávání. Řazení bych mohl implementovat tak, že bych do svojí aplikace načetl všechny řádky z db, pak seřadit a zobrazil, to samé u porovnávání a vyhledávání, ale to není nejšťastnější.

[Kit]

Takové použití databáze je úplně zcestné. Pokud bys chtěl řadit záznamy až ve skriptu, databázi zřejmě nepotřebuješ. Klidně bys mohl použít FS s utilitami nebo KVS.

l0gik ti navrhl, abys generoval SQL PHP skriptem. V tom skriptu můžeš podchytit odlišnosti jednotlivých SŘBD. Také můžeš zkusit ODBC nebo PDO. Ovšem pokud máš choutky řadit záznamy z databáze ve skriptu, zřejmě nemáš mnoho dat. Pokud chceš univerzální řešení, místo databáze použij raději XML a XSLT.

Univerzální nástroj neexistuje. Měl by ses s tím smířit.

[pavlix]

Pokud chceš univerzální řešení, místo databáze použij raději XML a XSLT.

Tak za to ti určitě poděkuje :). XSLT je krásná věc pro ty, kteří potřebují promrhat spoustu času.

[xkucf03]

To bych ani neřekl Akorát je to úplně jiný přístup k datům než relační (byť se tam nějaké analogie dají najít).

Původnímu tazateli bych doporučil se podívat na hotová řešení – ORM (Hibernate) nebo aplikace, které fungují nad více různými SŘBD (Drupal). Psát něco takového na koleně není úplně triviální.

[pavlix]

Mně se to před časem zalíbilo... hrál jsem si s tím... ale v reálných případech jsem obvykle místo XSLT použil nějaký obecný programovací jazyk, a pokud to šlo tak místo XML nějaký rozumnější formát na uložení dat.

[Kit]

Napsal jsem si pokusné diskusní fórum v XSLT a funguje velmi rychle i při velké zátěži. Netvrdím, že je to univerzální zázrak, ale pro menší objemy dat je to často výhodnější řešení, než použití databází. Zejména tam, kde je čtení mnohem častější, než zápis (drtivá většina webů).

[hispik]

Já jsem NEPSAL, že to chci řadit přímo v aplikaci, já psal že je to nevhodné. Mě jde o toto:
příklad mysql:

pokud budu chtít řadit podle sloupce "jméno" česky, pak musí být tento sloupec v utf8_collate_cs a je hotovo, nebo v utf8_bin a pak provádět order by convert using ... a je hotovo atd. Tzn. hledám takové řešení, které by bylo pro databáze podobné, abych nemusel u každé speciálně měnit logiku celého dotazu tzn. jednou mám sloupec přímo v požadovaném collate, podruhé převádím do pož. collate apod., tzn. hledám nějaký nejvíce společný "znak", který podporují různé databázové stroje (hlavně proto, že konvertování něco stojí i s f. indexy).

[kuka]

Zrovna toto se myslim mezi databazemi celkem dost odlisuje. Konkretne v Oracle lze radit a porovnavat celkem jakkoliv (case sensitive, insensitive, podle locale). Pro nektere situace staci mit nastavene vlasnosti session, pro nektere scenare je ale treba uvadet to primo do dotazu (napr. pri pouziti like). Asi bych se snazil maximalne vyjit z SQL normy a specificke pozadavky resit pripadne rozpadem kodu dle pouzite databaze - pokud potrebujes neco specialniho tak se tomu proste nevyhnes (pokud to nepresunes na aplikacni vrstvu).

[pavlix]

Netvrdím, že je to univerzální zázrak, ale pro menší objemy dat je to často výhodnější řešení, než použití databází.

Trošku mi vadí, když se ve větě porovnává konkrétní formát nějaké databáze s databází obecně. Svět ukládání dat je široký a takhle je to strašně zavádějící.

Zejména tam, kde je čtení mnohem častější, než zápis (drtivá většina webů).

No... nevím... zkoušel jsi v reálu srovnat rychlost tahání dat z XML pomocí XSLT a za relační databáze SQLite? Ona totiž SQLite při čtení nemusí být vůbec špatná. A další věc je, že to nejsou jediné dva přístupy... a já bych často zvolil řešení, které se rychleji napíše a bude třeba i pomalejší (zvlášť v případech, kdy tu rychlost uživatel nepozná).

[xkucf03]

a já bych často zvolil řešení, které se rychleji napíše

Přesně k tomu někdy používám XSLT – jednoúčelová šablona se dá uplácat velmi rychle a není potřeba to moc řešit a pak ji akorát pustíš v jEditu nebo pomocí Antu a je to – rychlejší než něco normálně programovat. Např. jsem takhle dělal převod MIBů (SNMP) do nějakého proprietárního XML formátu – snadno a rychle a to se vyplatí

(tím tedy nechci říct, že by se XSLT hodilo jen na tyhle věci)

[pavlix]

Přesně k tomu někdy používám XSLT – jednoúčelová šablona se dá uplácat velmi rychle a není potřeba to moc řešit a pak ji akorát pustíš v jEditu nebo pomocí Antu a je to – rychlejší než něco normálně programovat.

Asi holt každý máme jiné vysledky... když jsem srovnával svoji práci v XSLT a Python/libxml2, tak to druhé bylo na většinu úloh, co jsem potřeboval, rychlejší na napsání. A to jsem dokonce s XSLT měl delší zkušenost než s tím libxml2.

Takže, XSLT je hodně zajímavé, nejspíš se časem dostanu k tomu ho zase na něco použít, ale jednak mi práce s ním na mnoho věcí vůbec nepřijde rychlejší než třeba ten Python (i když bych našel věci, kde ano, ale nebývá to ukládání dat), a druhak to nemá do téhle diskuze žádnou vypovídací hodnotu.

Vypovídací hodnotou to nemá proto, že jakmile máš něco už spraseno do XML, tak se ti úplně změní situace. Tzn to, co funguje líp na XML (pokud vůbec), nemusí líp fungovat na data obecně. A musím říct, JSON mi na ukládání strukturovaných dat vychází většinou daleko lépe než XML, když už se teda bavíme o textových souborových formátech (versus binárních současně přistupované databáze či socketové databáze).

[Josef Kufner]

Koukni na dibi (perlička) a podobná udělátka. Ty tě odstíní od hromady drobných odlišností. SQL pak nebude soubor obsahující dotazy, ale jednoduchý skript, jak už bylo řečeno předemnou. A vůbec doporučuju si udělat jednoduchý instalátor, který se o databázi postará automaticky a integrovat ho do aplikace.

Co se zpracování textu týče, je na to MySQL velice dobře a i podstatně lépe než mnohé "lepší" databáze.

Omezovat se jen na společné vlastnosti všech podporovaných databází ti přinese víc problémů než užitku. Dobře vyřeš zvládání odlišností a bude ti hej.