Názor k článku evitaDB: základy dotazovacího jazyka evitaQL od Jan Novotný - SQL má tu výhodu, že je obecně známé,...

SQL má tu výhodu, že je obecně známé, ale má také spoustu nevýhod. Je to "string based" jazyk, se kterým se nepracuje dobře z programového hlediska - buď se spojují stringy, nebo se nad tím buduje další vrstva abstrakce (výrazového stromu, který se na string přeloží až těsně před předáním do databázového ovladače). Pokud chcete nad SQL vybudovat REST/GraphQL API, tak pravděpodobně také skončíte u nějakého vlastního DSL, protože posílání SQL v requestu nedává moc smysl - proč tedy rovnou nepracovat s jazykem, který je velmi podobný jak z nativního kódu, tak i z pohledu webových API a zároveň rovnou reprezentuje výrazový strom se kterým se dobře pracuje jak na klientu, tak na serveru?! Zároveň budou všichni zainteresovaní (jak frontendisti, tak backendisti) mluvit "stejnou" řečí a tím spíš si budou více rozumět.

Poznámka: o našich webových API bude pojednávat další článek série.

Trailing comma je dobrá připomínka - rovnou jsem založil issue https://github.com/FgForrest/evitaDB/issues/493 a s kolegy to probereme. Už jsem nad tím také přemýšlel, že to zbytečně komplikuje život.

Co se týká množství dotazů - docházíme k závěru, že tahle myšlenka se třeba v prostředí komponentově orientovaných frameworků (např. Next.JS) špatně realizuje a zamýšlíme se nad tím, že bychom dokázali optimalizovat a přepoužívat mezivýsledky napříč různými dotazy, pokud jsou poslány v rámci jedné dávky (batche) dotazů. Tj. analogii k request collapsing technice ve Varnishi - i když u nás by se jednalo o sdílení mezivýsledků na granulárnější úrovni než je celý dotaz. Stále nám ale dává smysl posílat více queries v rámci jediného requestu kvůli amortizaci nákladů na request/response režii. Velikost by v prostředí HTTP/2 nemusel být úplně zásadní problém. Tady uvidíme, co nám ukáže praxe.

Vyhledávání podle embeddingů je samo o sobě obrovská kapitola. Už teď existují databáze, které to dělají skvěle - např. Vespa.ai. Osobně mi dává smysl v nejdříve podporovat propojení s těmito specializovanými databázemi než se snažit tuto problematiku pokrýt vlastními silami. V tomhle směru se zatím teprve rozkoukáváme (https://github.com/FgForrest/evitaDB/issues/258).

Celkově děkuji za velmi cenný feedback!