SQL select

[Ondrej Nemecek]

Javě a ORM se vyhýbám obloukem, takže o nich nic nevím. V tuhle chvíli jsou Hstore i Jsonb dost jednoduché typy, které podporují základní operace (...)

Děkuji Pavlovi Stěhulovi za čerstvé zprávy z bojiště a za odkazy. Postgres je bezvadná databáze a pokud tam začnou fungovat i tyhle věci, bude to skvělé (a až bude ta podpora multicore CPU pro jeden query, bude to ještě lepší).

Jinak by to bylo celé asi na obsáhlou debatu - kdy použít JSON, kdy XML a kdy sáhnout rovnou k objektové databázi. Ale je to přliš široké téma, asi nemá smysl to tady řešit.

[Reklama]

[e3k]

ten tvoj:

SELECT DISTINCT ID from TBL WHERE Vlastnost=A and (Vlastnost=B OR Vlastnost=C)

je na tento ucel presne to co hladas.

To je na nic, tabulka obsahuje páry "jedno ID <-> jedna vlastnost" , takže těžko použiju jakejkoliv výraz obsahující "AND", protože mi nemůže dát nikdy žádný výsledek.

mas pravdu to som prehliadol.

podla vsetkeho firebirdsql podporuje INTERSECT operator takze tu kveru mozes poskladat takto ():

SELECT ID from TBL WHERE Vlastnost=A
INTERSECT
SELECT ID from TBL WHERE Vlastnost=B
INTERSECT
SELECT ID from TBL WHERE Vlastnost=X
INTERSECT
SELECT ID from TBL WHERE Vlastnost=Z
INTERSECT
(
SELECT ID from TBL WHERE Vlastnost=E
UNION
SELECT ID from TBL WHERE Vlastnost=F
)

to stym E,F by bol ten OR

[Raskal]

Sám jsem nedávno vymýšlel jeden takový dynamický EAV, musel jsem přidat přes triggery aktualizované indexové tabulky, aby bylo hledání dost rychlé, následné složení všech dat náležejících k jedné entitě ale zůstalo stále dost pomalé, takže bych měl přidat ještě další tabulku, kde budou data entity pohromadě už připravená... => jinými slovy jsem implementoval něco, co bych u Jsonb nebo Hstore měl už asi automaticky hotové. Existuje tam možnost nějaké validace dokumentů? Cílem by v mém případě bylo, aby část databáze byla dynamicky definovatelná, aby si strukturu mohl uživatel sám nadefinovat a vytvořené dokumenty vůči definici pak validovat.

Uvítám nějaké zdroje k výše řečenému.

@Ondrej - ve svych projektech (stredne velke webove aplikace; Java/Hibernate) pouzivam pro bussiness objekty komplexni datove schema zalozene na EAV (genericke atributy bussiness objektu definovane v datech, stromy bussiness objektu, obecne grafy bussiness objektu). Vlastnosti reseni jsou:
* databazi pouzivam pouze jako uloziste dat a logiku ridim v transakci z aplikace (uplne jsem opustil zpusob vytvareni aplikaci na strane DB),
* editace a cteni jednoho objektu trva rozumne dlouho (x1-10ms podle rychlosti DB; DB nejlepe na lokalnim stroji, protoze precteni jednoho objektu znamena vice dotazu; pocet dotazu zavisi na architekture datoveho modelu),
* pro publikaci objektu (renderovani stranky) mam k dispozici nakesovane objekty, takze rychlost jejich pouziti je ekvivalentem pouziti POJO,
* synchronizace kese objektu a DB se deje v ramci modifikace objektu pomoci servisni vrstvy, ktera se postara o zneplatneni polozek v kesi.
* 2 mody pristupu k objektum: cteni a editace.
* Vyhodou je pouzivani pouze relacni DB pro veskera ulozena data a tim nesporna vyhoda prace v jedne reansakci.
* Zdanlivou nevyhodou tohoto pristupu je, ze se data musi vejit do pameti. Pokud ale ma byt DB svizna, musi splnovat stejny pozadavek.
Jadro, ktere se o to stara, je relativne male (cca 20.000 radek kodu) a dovoluje mi vyvoj datoveho modelu s prakticky neomezenenou slozitosti a to diky tomu, ze jsem pro tento specialni pripad uspokojive vyresil dva protichudne pozadavky. Cela jedna aplikace je uz nasobne vetsi.
Odezvy na webu jsou vytecne. Az na vyjimky (velke stranky) vzdy do 100ms, prumer cca 50ms.

Raskal

[Pavel Stěhule]

* Zdanlivou nevyhodou tohoto pristupu je, ze se data musi vejit do pameti. Pokud ale ma byt DB svizna, musi splnovat stejny pozadavek.

Jenomže relační databáze pracuje s pamětí výrazně efektivněji - a pokud jí paměť dojde, tak při dobře navrženém schématu neztratí výkon fatálně - resp - celá ta technologie je navržena tak, aby fungovala i s relativně malou pamětí - samozřejmě, nesmíte používat EAV.

[Kit]

@Ondrej - ve svych projektech (stredne velke webove aplikace; Java/Hibernate) pouzivam pro bussiness objekty komplexni datove schema zalozene na EAV ...
... Jadro, ktere se o to stara, je relativne male (cca 20.000 radek kodu) ...

Takové rozežrané jádro je relativně malé?

Odezvy na webu jsou vytecne. Az na vyjimky (velke stranky) vzdy do 100ms, prumer cca 50ms.
Raskal

Supluje to SQL, tak se nediv, že je to tak líné.

[Reklama]

[Raskal]

* Zdanlivou nevyhodou tohoto pristupu je, ze se data musi vejit do pameti. Pokud ale ma byt DB svizna, musi splnovat stejny pozadavek.

Jenomže relační databáze pracuje s pamětí výrazně efektivněji - a pokud jí paměť dojde, tak při dobře navrženém schématu neztratí výkon fatálně - resp - celá ta technologie je navržena tak, aby fungovala i s relativně malou pamětí - samozřejmě, nesmíte používat EAV.

Ano, sql databaze jsou pametove efektivnejsi, je to ale jen linearni parametr toho celeho systemu. Pametova zavislost aplikace je linearne zavisla na pametove narocnosti databaze a zaroven aplikace nemusi mit uplne vsechna data permanentne v pameti. Mam-li napriklad 5GB dat v DB, aplikace je cca 10x narocnejsi, ale potrebuje z toho permanentne kesovat jen 1GB dat z DB, tak se mozna vejdu i do 16GB RAMky.

[Raskal]

@Ondrej - ve svych projektech (stredne velke webove aplikace; Java/Hibernate) pouzivam pro bussiness objekty komplexni datove schema zalozene na EAV ...
... Jadro, ktere se o to stara, je relativne male (cca 20.000 radek kodu) ...

Takové rozežrané jádro je relativně malé?

Odezvy na webu jsou vytecne. Az na vyjimky (velke stranky) vzdy do 100ms, prumer cca 50ms.
Raskal

Supluje to SQL, tak se nediv, že je to tak líné.

Ano, 20k radku kodu povazuji za maly kus kodu vzhledem ke sluzbe, kterou poskytuje.

50ms odezvu webove aplikace povazuji za vytecnou a nikoliv za "líné". Vystup kazde stranky je potencialne unikatni a nekesuje se.

[Zdenek Henek]

Obvyklé řešení je založené na vícenásobném selfjoinu, které by mělo být docela rychlé pokud podmínkám bude odpovídat tak do 3% řádků. Potom už asi může být rychlejší scan s HAVING.

Jedná se o synchronizaci dat mezi databází dodavatele a e-shopem, která probíhá max 1x denně a jedná se o pár tisíc položek (z nichž se dál zpracovává jen pár set) Trvá to v řádu vteřin a nějaký výrazný skokový nárust objemu dat se nedá očekávat, takže zatím je to v pohodě.

Ale děkuji, aspoň jsem o něco chytřejší. Většinou pracuju s SQL jen v rámci vlastních projektů a datový modely si vytvářím tak, aby to bylo co nejpohodlnější a nejrychlejší na používání. Zpracování cizích databází (a ještě doprasených, většina dat nesmyslně rozházená do desítek malých tabulek s hromadou vazeb mezi nima, dotaz pro získání 10ti sloupců znamená 7 joinů) není zrovna můj koníček :-D

Pokud je to jen par tisic radek, tak proc celou tabulku nenacpete do pameni a pak pouzit jen key, value dotazy na strukturu v pameti?
Pripada mi to v tuto chvili efektivnejsi, nez pouziti sql dotazu.

[Kolemjdoucí]

* databazi pouzivam pouze jako uloziste dat a logiku ridim v transakci z aplikace

Dosud jsi se nesetkal s větším projektem, zatím jsou to školní úlohy.
Jakákoliv prakticky nasazená reálná úloha skončí tak že se z nutnosti začnou vytvářet stored procedure na SQL serveru, následně ORM a Hibernate se tak stanou těžko použitelnými. Může se to obkecávat jak dlouho chce, stejně se to vždy stane.

[Tuxik]

podla vsetkeho firebirdsql podporuje INTERSECT operator takze tu kveru mozes poskladat takto ():

kdyz jsem tohle videl, skoro jsem se zaradoval, ale bohuzel, firebird intersect nepodporuje (alespon ne v posledni stable verzi).

[Tuxik]

Upraveno, otestováno, řešení s naskládáním parametrů do BLOBu v nově vytvořeném VIEW funguje pro moje potřeby dostatečně dobře. V podstatě by mě zajímalo řešení, jak to udělat bez toho nového VIEW (nevím, jestli to celý jde nějak naskládat do nějakýho jednoho selectu klidně s dalšíma vloženýma).

Co se týče různých profi řešení nahrát to celý do paměti a podobně, nápady jsou to pěkný, ale celý je to na virtuálu, kde toho běží víc a na takový fórky tam opravdu není HW a nebudu ho kvůli tomuhle řešit :-)

A co se týče přístupu Kolemjdouciho, "všichni jsou amatéři, já jedinej tu dělám s velkýma DB a já jedinej to umím dobře", tak k tomu nemám slov. Přiměřený funkční řešení odpovídající situaci nevymyslí, protože i když existuje (a jsem presvědčenej o tom, ze jich je víc a že nějaké hezčí ještě najdu i když už v podstatě o nic nejde), tak je asi moc deformovanej podnikovým prostředím na to, aby dokázal vytvořit řešení pro obyčejný lidi. Vidím to v práci, RAM, CPU a disky přihazuju do serverů pomalu vidlema, protože co chvíla přijde někdo z vývoje s tím, že něco předělává, aby to běželo o 10 procent rychleji a stačí mu k tomu jenom dvakrát víc jader CPU a 4x víc RAMky. Jestli jste si nevšiml, jedná se o malej projekt, nejedná se o žádnej kritickej systém s tisícema paralelních přístupů a  nevydělá si to ve výsledku ani na kafe, který u něho vypiju, natož na cokoliv jinýho.

[Kolemjdoucí]

To je nedorozumění, odpověď byla pro Raskal.

Univerzální optimální řešení problému Tuxik v SQL DB není dosud známo, neznají ho ani sami tvůrci SQL DB. Procházení všech řádků tabulky pořád znovu je funkční, ale ne optimální.

[Kit]

Jakákoliv prakticky nasazená reálná úloha skončí tak že se z nutnosti začnou vytvářet stored procedure na SQL serveru, následně ORM a Hibernate se tak stanou těžko použitelnými. Může se to obkecávat jak dlouho chce, stejně se to vždy stane.

Konečně něco, s čím mohu plně souhlasit.

[podlesh]

Jsonb nebo Hstore by pro nově navrhovanou databázi byly asi ideální, akorát nevím, jaká je podpora v ORM nástrojích? Můžete doporučit nějaké zdroje k tomu? Zajímá mě hlavně java.

V ORM nástrojích typicky je možné definovat vlastní typy, takže tam jen doplníš převod z/do byte[] (nebo stringu, pokud místo jsonb použiješ normální json nebo xml).

Triviální (ale reálný) příklad pro JSON:

Kód: [Vybrat]

    @Column(name = "custom_data")
    @Lob
    @Type(type = "org.codehaus.jackson.node.ObjectNode")
    private ObjectNode customData;


To co popisujes funguje jen pro konverzi BLOB => Java class. Pokud mas nejaky komplexni datavy typ v databazi a chces ho prevest na tridu, tak musis pouzit posledni verze JPA (2.1) - Attribute Converter anebo Entity Listener.

Jo, pravda, tohle nebude stačit pokud chci opravdu používat ORM, tedy podle jednotlivých položek uvnitř komplexního typu hledat nebo je dynamicky donačítat podle potřeby. Na druhou stranu, právě tato napsané aplikace jsou důvodem, proč všude vidíš lidi co před ORM varují (zde například Pavel Stěhule a Kolemjdoucí).

Osobně se mi osvědčilo použít ORM jen pro konverzi dat a základní CRUD a pro jakékoliv složitější věci stejně psát konkrétní SQL dotazy (a DDL samozřejmě vždy dělat ručně, resp. nechat si vygenerovat základ a pak dotahnout). Tedy v podstatě spíš iBatis (myBatis) přístup. Lze použít i pro Hibernate/JPA, ale vyžaduje disciplínu.

[Raskal]

* databazi pouzivam pouze jako uloziste dat a logiku ridim v transakci z aplikace

Dosud jsi se nesetkal s větším projektem, zatím jsou to školní úlohy.
Jakákoliv prakticky nasazená reálná úloha skončí tak že se z nutnosti začnou vytvářet stored procedure na SQL serveru, následně ORM a Hibernate se tak stanou těžko použitelnými. Může se to obkecávat jak dlouho chce, stejně se to vždy stane.

Backendy pro Webove aplikace navrhuji a implementuji profesionalne jiz pres 10 let a mam za sebou vyvoj nekolika velkych projektu s navstevnosti okolo 100.000 denne.

Tvoje tvrzeni povazuji za nespravne. K tomu, co jsem zde napsal, me vedou prave dluhodobe zkusenosti a implementace existujicich projektu.