neco jineho nez relacni DB stroj? (dlouhe)

[Ing. Pavel PaJaSoft Janousek]

> Zacinam byt vuci relacnim databazim se SQL rozhranim skepticky.
> Sice urcitou tridu problemu zjednodusuji, ale poradny abstraktni
> pohled na data v podstate znemoznuji.

	Ac to naprvni pohled vypada tak, domnivam se, ze dotazovaci podmnozina
(DQL - Data Query Language a DML - Data manipulation language) jazyka
SQL jako takova neni nutne svazana s relacnimi daty. To ze 99.9%
implementaci SQL pouziva ciste relacni model je ciste vec implementace.

> Cekal bych, ze jiz mozna existuje nejake API v OOP jazyce,
> ktere bude schopno instance nejake tridy, kterou si nadefinuji
> strkat do nejakeho datoveho prostoru. Bude umet data indexovat.
> Bude umoznovat transakcni zpracovani. (Pozadavek mechanismu zalohovani
> si netroufam polozit.) ...
> 
> Kdyz clovek sahne po nejake relacni stroji, je asi jedno jakem,
> jde cela abstrakce do prcic. Musim utrhnout data od funkci nad nimi
> a strkat je do DB (pouzit typy a funkce, ktere se mi vubec nelibi
> a je to ukrutna pakarna).
> V DB zase nejsem schopen rozume s daty nakladat
> bez tech mych obalujicich funkci. Stored procedury? S tema toho clovek
> moc neporidi a nebudu preci svuj kod duplikovat, jednou v aplikaci,
> jednou v DB - fuj. Jeste nejdal je na tom PostgreSQL, kde muzu psat
> procedury na serveru v C, Dopsat typy a operatory nad nimi v C.
> Mozna to je ten spravny smer.
> Obecne je mi cely "uzasna" sila DB stroje na nic, pokud do nej
> neprotlacim potrebne funkce (funkce komparace apod.).
> Vubec nemluvim o tom, ze co DB stroj to rozdily v jazyce v datovych
> typech ...

	Mate nepochybne na mysli takove ty abstrakce jako Nastenka a zapsani na
ni, smazani z ni (napr. jayk Linda)... - ja se domnivam, ze funkcni
implementace zejmena v simulacich existuji (bohuzel toto je oblast,
ktera komerni svet zrovna 2x nezajima, takze popularizaci problemu~,
implementaci' apod. necekejte).

	Domnivam se, ze data interne muzou byt klidne relacni, pokud to DB
stroji jako takovemu pomuze, problem je externi pohled na ne... - clovek
vetsinou mysli ve vztazich (mnoziny nejsou od veci), proto vytvari
relacni databaze, existuji ale problemy, ktere to neumoznuji takto
pojmout.

	DB stroj jako takovy by mel byt skalovatelny, distribuovatelny atd.
atd... - ale toto by mel byt DB stroj uvnitr, Vas by mela zajimat ta
abstrakce ala nastenka - bud v DB neco je nebo neni, ale kde to je, na
kterem serveru to bezi, ktery CPU to zpracovava Vam ma byt jedno - v
soucasne dobe jsou to v beznych systemech bohuzel az prilis velke
abstrakce - myslim si, ze tady je pomerne prima umera vykon na jednotku
zaznamu ku mire abstrakce - a uprimne receno, soucasny CPU vykon neni
nijak oslnivy (krome pocitani cislicek a faktorialu;-))).

> <ODBOCKA K DBI>
> Casto si laik mysli, ze DBI v Perlu sjednocuje zpusob prace s databazi.
> To IMHO nejde.
> Troufam si tvrdit, ze vyhoda DBI je
> v tom, ze ma na urcite urovni stejny pohled na DB
> (connection, prepare, execute, fetch ...). Takze jako programator
> to mam na tehle urovni stejne u ruznych DB.
> Vubec uz neni pravda, ze bych snad mohl DB pod DBI zamenovat.
> To jsem si uz nabehl. S tak uzkou mnozinou SQL,
> ktere by alespon dva ruzne DB podporovaly
> se neda v konkretnich pripadech pracovat. (vyjma skolni pripady)
> Bezpochyby v tom co se v soucasnych databazich dalo sjednotit
> je DBI rohrani Perlu asi spicka.
> </ODBOCKA K DBI>

	K tomu mam jen jednu poznamku - ANSI SQL92 - pokud mam DB stroje, ktere
bez vyhrad splnuji standard, mam nad nimi jakekoli rozhrani, mohu beze
vseho zamenovat DB stroje... Ja nez DBI bych se spise priklanel k ESQL
ci jeste vice ESQL pro objektove jazyky obecne (C++ v tomto pripade neni
default, alebrz Java), mam zkusenosti s migraci mezi PostgreSQL (ECPG) a
Oracle (Pro*C) a krome nestardarizovanem konekteni do DB je vse ostatni
naprosto bez problemu...

> Nevi tedy nekdo o databazi, ktera by mela interface v podobe API
> dejme tomu v C++ nebo Java a dovolovala primo manipulace s objekty?

	A proc? Na jednu stranu se Vam nelibi, ze nemuzete mit opravdu vysoky
stupen abstrakce, na druhou chcete take na pomerne nizkou uroven.
Myslim, ze oboji nepujde nikdy...

> Za namety dekuji.

	Nekritizuji vase nazory, moje jsou nekde rozdilne, spise to berte jako
temata ke zvazeni...

> PS: Pokud si nekdo mysli, ze jsem ujel a chce mi ukazat, ze relacni
>     DB stroj zvladne vsechno elegantne. Tak vezmeme muj konkretni
>     pripad. Mam netrivialni schema (vice entit) provazanych
>     a pozaduje se po me, abych zaznamenal kompletni historii dat.
>     Kdo co kdy zmenil (z ceho na co).
>     Chce se po me, abych zajistil pristupova prava na urovni
>     operaci nad daty (pristupova prava zavisi na hodnote dat
>     a dynamicky - jsou definovana daty).
>     Strkam do DB binarni data o jejichz strukture nema DB potuchy,
>     ale mela by mit.
>     (Ta aplikace je jakasi certifikacni autorita :-)
>     Ja to nejak vyreseno mam, ale moc se mi to nelibi.

	Vim o podobne tride problemu - zapomeneme-li na relacni model dat, pak
uplne elegantni reseni (vcetne algoritmu s optimalni casovou slozitosti)
je grafova struktura a 99% problemu se da redukovat na Hledani cesty a
Barveni grafu (pomene elegantni algoritmy jak pro UNI, tak pro MULTI
procesory - vcetne jednoucelovych 'pitomcu').
Nechtejte vsak po mne tyto veci implementovat v relacnim modelu...;-)
Urcita moznost je implementace vlastniho VirtualFS, ktery bude
prezentovat stromovou strukturu... - pravdepodobne Acyklicke grafy...
ale implementaci skutecne nemam.

-----------------------------------------------------------------------
Ing. Pavel Janousek (PaJaSoft)                 FoNet, spol. s r. o.
Vyvoj software, Intranet / Internet          Anenska 11, 602 00  Brno
E-mail: mailto:Janousek na FoNet.Cz             Tel.: +420  5  4324 4749
SMS:    mailto:P.Janousek na SMS.Paegas.Cz      Fax.: +420  5  4324 4751
WWW:    http://WWW.FoNet.Cz/               E-mail: mailto:Info na FoNet.Cz
-----------------------------------------------------------------------