Mají tabulkové databáze v dnešní době smysl?

[listoper]

To je to COBOLovské myšlení, které se nepodařilo vymýtit - jen převléklo kabát, a objevilo se pod jinou jmenovkou - ORM.

Nechci ORM obhajovat, ale musím :-) Principielně není problém, aby dobré ORM posílalo optimální SQLka. Problém není myšlení, ale to, že ta ORM jsou blbě napsaná. Bohužel všechna, a to dělá pak ten blbej dojem.

Za pravnika bych te nechtel 

[Reklama]

[BoneFlute]

To je to COBOLovské myšlení, které se nepodařilo vymýtit - jen převléklo kabát, a objevilo se pod jinou jmenovkou - ORM.

Nechci ORM obhajovat, ale musím :-) Principielně není problém, aby dobré ORM posílalo optimální SQLka. Problém není myšlení, ale to, že ta ORM jsou blbě napsaná. Bohužel všechna, a to dělá pak ten blbej dojem.

Za pravnika bych te nechtel 

Tak dělám, co umím. Co neumím, nedělám :-)

[Kiwi]

To je to COBOLovské myšlení, které se nepodařilo vymýtit - jen převléklo kabát, a objevilo se pod jinou jmenovkou - ORM.

Nechci ORM obhajovat, ale musím :-) Principielně není problém, aby dobré ORM posílalo optimální SQLka. Problém není myšlení, ale to, že ta ORM jsou blbě napsaná. Bohužel všechna, a to dělá pak ten blbej dojem.

Kde jsem něco podobného už jenom slyšel... "Komunismus principiálně může v pohodě fungovat. Bohužel, zatím to všichni dělali blbě."

[BoneFlute]

To je to COBOLovské myšlení, které se nepodařilo vymýtit - jen převléklo kabát, a objevilo se pod jinou jmenovkou - ORM.

Nechci ORM obhajovat, ale musím :-) Principielně není problém, aby dobré ORM posílalo optimální SQLka. Problém není myšlení, ale to, že ta ORM jsou blbě napsaná. Bohužel všechna, a to dělá pak ten blbej dojem.

Připadá mi, že ORM svádí k programování ve stylu:

Kód: [Vybrat]

sum = 0
foreach a = collection_of_a()
  if test(a) then
    b = collection_of_b(a.b_id)
    if test(b) then
      sum += b.val
return sum
Není mi jasné, jak tohle dobré ORM zoptimalizuje, i když je jasné, že se to dá přepsat do jednoho SELECTu s JOINem dvou tabulek.

Jsi si jist, že za to může to ORM?
Setkal jsem se s kódem, který ORM nepoužíval a dopadlo to stejně.

Já na ORM pohlížím jako na něco, co by mě mělo usnadnit rutinní práci. Neočekávám, že zajistí, že se nebudu střílet do nohy.

[BoneFlute]

To je to COBOLovské myšlení, které se nepodařilo vymýtit - jen převléklo kabát, a objevilo se pod jinou jmenovkou - ORM.

Nechci ORM obhajovat, ale musím :-) Principielně není problém, aby dobré ORM posílalo optimální SQLka. Problém není myšlení, ale to, že ta ORM jsou blbě napsaná. Bohužel všechna, a to dělá pak ten blbej dojem.

Kde jsem něco podobného už jenom slyšel... "Komunismus principiálně může v pohodě fungovat. Bohužel, zatím to všichni dělali blbě."

A to nevíš, že já ORM nemám rád, a to hlavně pro tu jejich snahu o objektovost :-P

[Reklama]

[MartinBeran]

Jsi si jist, že za to může to ORM?
Setkal jsem se s kódem, který ORM nepoužíval a dopadlo to stejně.

Já na ORM pohlížím jako na něco, co by mě mělo usnadnit rutinní práci. Neočekávám, že zajistí, že se nebudu střílet do nohy.

Myslel jsem, že ORM má skrývat fakt, že data jsou v relační databází a prezentovat mu je, jako by byly v nějakém úložišti objektů. Pak mi ale připadá přirozené, že programátor s objekty pracuje po jednom a explicitně přechází mezi nimi pomocí vzájemných odkazů a při tom neřeší, že každý krok znamená dotaz do databáze. Není mi moc jasné, jak by mělo ORM vypadat, aby navádělo k efektivní práci s databází a zároveň nevypadalo jako SQL přebalené do jiné syntaxe.

[BoneFlute]

Jsi si jist, že za to může to ORM?
Setkal jsem se s kódem, který ORM nepoužíval a dopadlo to stejně.

Já na ORM pohlížím jako na něco, co by mě mělo usnadnit rutinní práci. Neočekávám, že zajistí, že se nebudu střílet do nohy.

Myslel jsem, že ORM má skrývat fakt, že data jsou v relační databází a prezentovat mu je, jako by byly v nějakém úložišti objektů. Pak mi ale připadá přirozené, že programátor s objekty pracuje po jednom a explicitně přechází mezi nimi pomocí vzájemných odkazů a při tom neřeší, že každý krok znamená dotaz do databáze. Není mi moc jasné, jak by mělo ORM vypadat, aby navádělo k efektivní práci s databází a zároveň nevypadalo jako SQL přebalené do jiné syntaxe.

Možná to tak někteří chápou, pak by měl Pavel s tím COBOLem pravdu.

Mě na SQL přijde revoluční právě ten deklarativní zápis. Pošleš engine algoritmus, a on ti vyplivne výsledky. Něco podobné je možné pozorovat u LINQ, nebo GraphQL. Díky tomu se opravdu můžu oprostit od detailů práce s databází (na druhou stranu mi přijde zase škoda vzdát se pokročilejších možností) aniž by to začalo být brutálně neefektivní.

V některých svých hračkách, co jsem dělal jsem měl specializovaný DSLko, kterým jsem se dotazoval na objekty, a pokoušel jsem se to mé pseudoORM přinutit, aby generovalo SQLka, která bych napsal stejně. Celkem to šlo.

Nebo jiný způsobem. Nette/Database to dělá tak, že dokáže zoptimalizovat i ten tvůj kód. Při prvním průchodu to provede všechny dotazy, to si nakešuje, a při dalších už to načítá hromadně. Mě ten způsob není moc sympatický, ale funguje to.

[MartinBeran]

Mě na SQL přijde revoluční právě ten deklarativní zápis. Pošleš engine algoritmus, a on ti vyplivne výsledky. Něco podobné je možné pozorovat u LINQ, nebo GraphQL. Díky tomu se opravdu můžu oprostit od detailů práce s databází (na druhou stranu mi přijde zase škoda vzdát se pokročilejších možností) aniž by to začalo být brutálně neefektivní.

Nechápu, co tenhle odstavec měl vyjadřovat. Jestli "oprostit od detailů práce z databází" znamená, že s databází komunikuju pomocí SQL, tak to nemá s ORM nic společného. Jestli to má znamenat, že díky deklarativnímu SQL se můžu oprostit od detailů použitím ORM, tak to není pravda.

V některých svých hračkách, co jsem dělal jsem měl specializovaný DSLko, kterým jsem se dotazoval na objekty, a pokoušel jsem se to mé pseudoORM přinutit, aby generovalo SQLka, která bych napsal stejně. Celkem to šlo.

U DSL specializovaného pro nějakou konkrétní aplikaci jsem ochoten věřit, že to může generovat rozumné SQL. Ale pak to asi nebude obecně použitelné ORM.

Nebo jiný způsobem. Nette/Database to dělá tak, že dokáže zoptimalizovat i ten tvůj kód. Při prvním průchodu to provede všechny dotazy, to si nakešuje, a při dalších už to načítá hromadně. Mě ten způsob není moc sympatický, ale funguje to.

I když pominu, že ten první průchod může trvat nechutně dlouho, tak jestli při dalších průchodech už nekomunikuje s databází a čte z keše, tak to bude mít minimálně dvě další nevýhody: 1. Keš může být hodně velká; 2. Bude to fungovat správně, jen když se data v databázi nebudou měnit.

[Kit]

Myslel jsem, že ORM má skrývat fakt, že data jsou v relační databází a prezentovat mu je, jako by byly v nějakém úložišti objektů. Pak mi ale připadá přirozené, že programátor s objekty pracuje po jednom a explicitně přechází mezi nimi pomocí vzájemných odkazů a při tom neřeší, že každý krok znamená dotaz do databáze. Není mi moc jasné, jak by mělo ORM vypadat, aby navádělo k efektivní práci s databází a zároveň nevypadalo jako SQL přebalené do jiné syntaxe.

Dobré ORM je jen vlhkým snem některých vývojářů. Pokud někdo chce používat kolekce místo tabulek, tak proč se snaží dělat konverzi mezi nimi? Proč nepracuje s databázemi, které s kolekcemi fungují nativně?

Výsledkem SELECTu v relační databázi je kolekce relací. Je velmi jednoduché takovou kolekci zpracovat objektově. Jakmile někdo volá SQL dotaz v cyklu, něco je hodně špatně.

[BoneFlute]

Mě na SQL přijde revoluční právě ten deklarativní zápis. Pošleš engine algoritmus, a on ti vyplivne výsledky. Něco podobné je možné pozorovat u LINQ, nebo GraphQL. Díky tomu se opravdu můžu oprostit od detailů práce s databází (na druhou stranu mi přijde zase škoda vzdát se pokročilejších možností) aniž by to začalo být brutálně neefektivní.

Nechápu, co tenhle odstavec měl vyjadřovat. Jestli "oprostit od detailů práce z databází" znamená, že s databází komunikuju pomocí SQL, tak to nemá s ORM nic společného. Jestli to má znamenat, že díky deklarativnímu SQL se můžu oprostit od detailů použitím ORM, tak to není pravda.

Naopak. Díky deklarativnímu SQL se můžu oprostit od detailu uložení dat. Stejně tak nějak musím u inteligentního ORM psát deklarativně a poněkud obecně.
Například u toho LINQ je to pěkně vidět. Nemůžu napsat

Kód: [Vybrat]

sum = 0
foreach a = collection_of_a()
  if test(a) then
    b = collection_of_b(a.b_id)
    if test(b) then
      sum += b.val
return sum

ale musím napsat:

Kód: [Vybrat]

src.iters.filter(\a -> ...).b.iters.filter(\b -> ...).sum()
To aby ten LINQ "pochopil" co má udělat.

I když kdo ví, třeba by zvládl i ten tvůj zápis. Zase tak dobře to neznám.

V některých svých hračkách, co jsem dělal jsem měl specializovaný DSLko, kterým jsem se dotazoval na objekty, a pokoušel jsem se to mé pseudoORM přinutit, aby generovalo SQLka, která bych napsal stejně. Celkem to šlo.

U DSL specializovaného pro nějakou konkrétní aplikaci jsem ochoten věřit, že to může generovat rozumné SQL. Ale pak to asi nebude obecně použitelné ORM.

Bylo to obecné DSL pro získávání obecných dat z ORM. Ale mělo to svá specifika a určitě i omezení.

Nebo jiný způsobem. Nette/Database to dělá tak, že dokáže zoptimalizovat i ten tvůj kód. Při prvním průchodu to provede všechny dotazy, to si nakešuje, a při dalších už to načítá hromadně. Mě ten způsob není moc sympatický, ale funguje to.

I když pominu, že ten první průchod může trvat nechutně dlouho, tak jestli při dalších průchodech už nekomunikuje s databází a čte z keše, tak to bude mít minimálně dvě další nevýhody: 1. Keš může být hodně velká; 2. Bude to fungovat správně, jen když se data v databázi nebudou měnit.

Nekešují se data, ale schema. Špatně jsem to popsal. Nejlépe osvětlí ukázka:

Kód: [Vybrat]

foreach ($users(10) as $user) {
    echo $user->title;
    foreach ($user->articles(10) as $article) {
        echo $article->title;
        foreach ($article->discuss(5) as $discuss) {
            echo $discuss->title;
        }
    }
}
Při prvním průchodu to vytvoří 51 dotazů, při druhém už jen tři, protože si odvodí, že ty articles a discuss může sloučit.
Možná, že ten tvůj příklad už by byl moc, možná by to zvládl. Ruku do ohně bych za to nedal.

Kód: [Vybrat]

$sum = 0
foreach ($base->where(test_a) as $a) {
    foreach ($a->where(test_b) as $b) {
        $sum += $b->val;
    }
}
return $sum;


[Kit]

Nebo jiný způsobem. Nette/Database to dělá tak, že dokáže zoptimalizovat i ten tvůj kód. Při prvním průchodu to provede všechny dotazy, to si nakešuje, a při dalších už to načítá hromadně. Mě ten způsob není moc sympatický, ale funguje to.

I když pominu, že ten první průchod může trvat nechutně dlouho, tak jestli při dalších průchodech už nekomunikuje s databází a čte z keše, tak to bude mít minimálně dvě další nevýhody: 1. Keš může být hodně velká; 2. Bude to fungovat správně, jen když se data v databázi nebudou měnit.

Nedává mi to smysl. Proč používat cache v aplikaci, když relační databáze mívají vlastní propracované cache? Také mi není jasné, proč by se aplikace měla opakovaně ptát na hodnoty, které už má.

[BoneFlute]

Nebo jiný způsobem. Nette/Database to dělá tak, že dokáže zoptimalizovat i ten tvůj kód. Při prvním průchodu to provede všechny dotazy, to si nakešuje, a při dalších už to načítá hromadně. Mě ten způsob není moc sympatický, ale funguje to.

I když pominu, že ten první průchod může trvat nechutně dlouho, tak jestli při dalších průchodech už nekomunikuje s databází a čte z keše, tak to bude mít minimálně dvě další nevýhody: 1. Keš může být hodně velká; 2. Bude to fungovat správně, jen když se data v databázi nebudou měnit.

Nedává mi to smysl. Proč používat cache v aplikaci, když relační databáze mívají vlastní propracované cache? Také mi není jasné, proč by se aplikace měla opakovaně ptát na hodnoty, které už má.

Viz můj následující příspěvek. Špatně jsem to popsal. Nejde o cache dat, ale o cache schematu. Nebo spíše logiky.

[Kit]

Nekešují se data, ale schema. Špatně jsem to popsal. Nejlépe osvětlí ukázka:

Kód: [Vybrat]

foreach ($users(10) as $user) {
    echo $user->title;
    foreach ($user->articles(10) as $article) {
        echo $article->title;
        foreach ($article->discuss(5) as $discuss) {
            echo $discuss->title;
        }
    }
}


Tohle vypadá strašně. Přitom na to stačí jen jeden SELECT, který relační databáze zvládne levou zadní. PDO to navíc dokáže uspořádat do stromu, takže s tím už není skoro žádná práce.

[OooO]

Jsi si jist, že za to může to ORM?
Setkal jsem se s kódem, který ORM nepoužíval a dopadlo to stejně.

Já na ORM pohlížím jako na něco, co by mě mělo usnadnit rutinní práci. Neočekávám, že zajistí, že se nebudu střílet do nohy.

Myslel jsem, že ORM má skrývat fakt, že data jsou v relační databází a prezentovat mu je, jako by byly v nějakém úložišti objektů. Pak mi ale připadá přirozené, že programátor s objekty pracuje po jednom a explicitně přechází mezi nimi pomocí vzájemných odkazů a při tom neřeší, že každý krok znamená dotaz do databáze. Není mi moc jasné, jak by mělo ORM vypadat, aby navádělo k efektivní práci s databází a zároveň nevypadalo jako SQL přebalené do jiné syntaxe.

Ano, ORM je zkrátka způsob, jak persistovat data objektů v relační databázi, ne interface pro efektivní práci s relační databází. Od tohohle rozdílu by se mělo odvíjet designové rozhodnutí, zda ORM použít.

[Někdo]

Nebo jiný způsobem. Nette/Database to dělá tak, že dokáže zoptimalizovat i ten tvůj kód. Při prvním průchodu to provede všechny dotazy, to si nakešuje, a při dalších už to načítá hromadně. Mě ten způsob není moc sympatický, ale funguje to.

I když pominu, že ten první průchod může trvat nechutně dlouho, tak jestli při dalších průchodech už nekomunikuje s databází a čte z keše, tak to bude mít minimálně dvě další nevýhody: 1. Keš může být hodně velká; 2. Bude to fungovat správně, jen když se data v databázi nebudou měnit.

Nedává mi to smysl. Proč používat cache v aplikaci, když relační databáze mívají vlastní propracované cache? Také mi není jasné, proč by se aplikace měla opakovaně ptát na hodnoty, které už má.

Dotaz do cache přímo v aplikaci je mnohonásobně rychlejší než dotaz do cache v databázi (protože tam to velmi zpomaluje komunikace po síti). A i na to aby se aplikace opakovaně neptala na hodnoty které už má se dá využít právě cache v aplikaci.