Když nejde změnit databází

6.1.2006 00:15 | Přečteno: 1025× | programátorské úvahy

Právě jsem objevil abclinuxu a založil si blog. Jiní při založení blogu napíšou jednoduchý zápisek typu "Mám nový blog", nebo prostě pošlou výpis hw konfigurace svého stroje. Já se rozhodl, že nic takového dělat nebudu, ale namísto toho jsem se rozhodl před vás postavit tvrdý oříšek. V poslední době jsem totiž čím dál víc stavěn před projekty, kterým důvěrně říkám "Kamikadze". A zrovna teď přede mnou leží jeden projekt, na kterém si asi vylámu zuby dřív, než ho vůbec začnu.

O co jde? Představte si informační systém, který vyvíjí asi 10 programátorů intenzivně po tři roky. Ten informační systém je ale postaven tak, že přímo využívá databázi Sybase ASA. Sice ne úplně přímo, ale přes ODBC rozhraní. Úkol zní: zajistit, aby informační systém mohl být převeden na jinou, výkonnější databázi. Mě osobně připadá, že to bez přepsání celého informačního systému nepůjde.

Ale zaujalo mě to jako problém. Cestou z práce chodím a přemýšlím, jestli přece neexistuje nějaký způsob, třeba složitější, kterým by bylo možné zajistit, aby informační systém pracoval nad jinou databází, aniž by ho bylo nutné přepsat.

Popíšu trochu situaci, vlastně spíš typickou konfiguracï informačního systému. Jedná se Linuxový server, na kterém je databáze Sybase ASA. Klienti jsou bohužel Windowsoví a jsou naprogramováni v Delphi. K databázovému serveru se přistupuje přes rozhraní ODBC. Problém je, že daná databáze je využívána ve svých schopnostech opravdu do posledního detailu. Velká část logiky informačního systému je naprogramovaná v databázových procedurách, triggerech a funkcích. Samotný klient už je jen prostý zobrazovač dat. Přesto dost často posílá celkem složité SQL dotazy plné různých triků a šitých přesně na míru databázi.

Vlastně si uvědomuji, že i mě samotnému by se takové řešení hodilo, protože sám jsem napsal pár prográmků jen tak pro radost, které pracují nad jednou určitou databází. Určitě bych teď po čase uvítal, kdybych mohl zvolit jinou databázi, než v okamžiku, kdy jsem prográmky psal.

Uvědomil jsem si, že tento problém nikdo nikdy neřešil, alespoň pokud vím a pokud mé internetové oko posílené googlem dohlédlo.

       

Komentáře

[alblaho]

Kdysi jsem přenášel naprosto triviální věc mezi MySQL, PostgreSQL a Firebirdem. Žádné trigry nebo storprocky. Jen pár tabulek a jednoduchých dotazů. Myslel jsem, že z toho porodím, nečekaná pruda.

Takže tohle fakt nemá řešení, to je lepší to napsat znovu.

[podlesh]

MySQL<==>PostgreSQL je ještě celkem v pohodě. Ten Firebird, ten je horší...

[miso]

Podla mna tie triggery a procedury by snad isli prepisat, ak ich neni vela, to snad kazda DB zvladne.
Skor tie SQL site na mieru, s tym sa asi neda pohnut ...
Ak existoval nejaky "prebalovac", ktory by zvladol previest dotaz do nejakeho metajazyka a spat na dotaz pre inu db, ale by zrejme fungovalo ako automaticke preklady, teda biedne

[tomm]

Nejsem si uplne jisty, ale nevyresil by to prechod na Enterprise verzi Sybase (Sybase ASE). Ta by mela byt vykonejsi. Pak pokud vim existuji jeste "drsnejsi" verze DB od Sybase (cosi na miru zelezu). Snad alespon mezi sebou by mohly byt z vetsiny kompatibilni. Prechod na neco uplne jineho je temer nemozny. Prenest datovy model je jeste sranda. Ale ty ulozene procedury, to bude strasne. Napade me snad jedine prekladac na miru, ale to je taky drsny orisek - bude muset "znat" data, se kterymi procedury pracuji atd. ...

[volvox]

Pokud je většina aplikační logiky napsaná přímo v db nemá smysl imho důvod migrovat na nějakou jinou z důvodu výkonu (jak víte, že to bude na jiné rdbms s výkonem lepší?). Výkon se řeší buď vyladěním samotné db, os, datových struktur, dotazů (např. query plans), nebo hardwarem (což je v naprosté většině případů nejlevnější - pokud to licence umožňuje).

V tomhle konkrétním případě to vypadá, že by se musel upravit datový model, přepsat všechen kód na straně db a dotazy na straně klientů. A to se prakticky rovná napsat to celé znovu od začátku, tj. při zmíněných deseti programátorech (kde jsou ostatní?) to znamená náklady v řádech miliónů.

Jistým možným řešením by bylo oddělit aplikační část systému - ponechat ji v Sybase a datové sklady - do jiné db, ale to už závisí na tom, jaký systém to je.