Puvodne jsem se zalekl hrozici narocnosti obecneho stromu, zvlast vzhledem
k moji neduvere k vykonnosti (casove i prostorove) XML konverzi.
Proto jsem uvazoval o dvou zjednodusenych formatech - konjunktivne disjunktnim
a disjunktivne konjunktnim (nebo tak neco). Potom jsem si ale uvedomil pomerne
samozrejmou vec - obecny strom, pokud podporuje operace s libovolnym poctem
parametru, sice muze dopadnout priserne, ale nemusi. Specialne vyse zminene
formaty formuli lze vyjadrit stromem o hloubce 2, tedy asociativnim polem stejne
hloubky jako pri primem vyjadreni.
Proto jsem se rozhodl ze odpovednost za nepretezovani XML kostaty a jinymi
extremnimi pripady stromu necham na navrzich ostatnich modulu, predevsim
testeru.

Predpokladam tedy nasledujici low-level rozhrani databaze:
    1) tabulka - jmeno tabulky pripadne pole jmen tabulek, pokud budeme
    vyzadovat slozitejsi dotazy ... coz asi budeme.
    2) metoda - co se vlastne ma provadet
	zatim me napadaji tyto metody:
	    select - vyber   zaznamu
	    insert - vlozeni zaznamu
	    update - modifikace zaznamu
	    updins - prvni nesamozrejma:
		pokud prislusny zaznam existuje, provede jeho update,
		v opacnem pripade ho vlozi. Atomicky.
    3) data - nejcasteji pole dvojic jmeno hodnota. Pri update lze uvazit
	i povoleni nekterych operaci - MySQL je v tomto ohledu velmi schopne
	a spoustu toho podporuje i norma. Uz pri updins bychom ale meli problemy.
	Tyto data budou pochopitelne pri insertu/update vkladana do tabulky.
	Pri selectu se pouzije pouze jmeno jako jmeno sloupce tabulky ktery
	pozadujeme, nebo alternativa:
	    opet se povoli operace, dvojice bude obsah
	a nazev sloupce. Pri vice tabulkach patrne nutne, ale nerad bych to pak
	prepisoval do ne-SQL (nerelacni ?) databaze ... opet se musime podivat
	co bude zapotrebi.
	    Je mozne ze do low-level rozhrani pridame podobne vychytavky s tim
	    ze je bude smet pouzivat pouze high-level rozhrani databaze
	    (ktere potom nebude zcela nezavisle, ale bude mit rekneme relacni
	    a nerelacni verzi)
    4) podminka - zde bude jiz uvedeny strom. Presna struktura:
	` - nazev operace. Toto jmeno bylo vybrano proto ze v MySQL nelze
	udelat sloupec s timto jmenem. Nevim jestli to pujde v ostatnich
	databazich, ale kazdopadne je to blbe jmeno pro sloupec.
	vyznam ostatnich polozek zavisi na druhu operace:
	
	AND, OR, ... 
	    ostatni polozky jsou dvojice jmeno hodnota pro operaci '=' nebo
	    podstromy
	FULLTEXT
	    phrase - fraze na vyhledani
	    hodnoty ostatnich polozek jmena sloupcu ktere se prohledavaji
	>, <, ..., LIKE, REGEXP, ...
	    l - levy operand, nejcasteji nazev sloupce
	    r - pravy operand
	Predpokladam ze pribudou dalsi operace, MySQL jich ma spoustu a nektere
	    dalsi bychom patrne mohli emulovat (rozepsat do MySQL operaci)

Navrzene rozhrani pochopitelne nema plnou silu SQL databazoveho dotazu
(o MySQL nebo dokonce PostgreSQL nemluve), coz osobne povazuji za nevyhodu,
ale da se s nim delat spousta veci a zda se mit rozumnou rozsiritelnost,
tedy pokud prijdeme na neco dalsiho snad se nam to povede pridat bez nutnosti
prekopavat prilis mnoho jiz hotoveho (tou dobou) kodu.

High-level rozhrani:
Presny navrh bude rizen potrebami ostatnich modulu, ale myslim ze uz muzu
naznacit par funkci:

    ulozeni zakladniho zaznamu - tedy musi zakladni zaznam ziskany vice ci mene
primo z formulare prepsat do podoby dotazu nebo pravdepodobne nekolika dotazu.
(updins do hlavni tabulky, nekolik updins do tabulky pouziti autoru)

    skryti pomocnych tabulek - je mozne ze z duvodu efektivity budeme nektere
zaznamy rozkladat do pomocnych tabulek, napriklad abychom snizili duplicity.
Je jiste ze to budeme delat pro opakovane zaznamy, jako jsou autori.
Tento fakt ovsem budeme maskovat jak pri vkladani tak pri selectu,
pokud mozno 1:1, tedy dotaz na virtualni tabulku prelozime na dotaz do
vice tabulek. (Teda ... v SQL to pujde jen pri select ...)

    skryti regularnich vyrazu - dotaz na 'neco podobneho $str' bude nutne
prelozit na jeden nebo nekolik regularnich vyrazu a dopocitat v php pomoci
funkci pro blizkost stringu. Tato cast bude dost narocna, je nutne ji vylepsovat
tak dlouho dokud nezacne uzivateli pripadat ze to opravdu umi najit podobny vyraz
 ...
zacneme pochopitelne necim na tema "zacina to stejne" OR "konci to stejne".

Poznamka: do direktorare sources jsem pridal hrubou verzi sestavovani SQL dotazu
z navrzeneho rozhrani a par dalsich pre-alfa casti SQL modulu.