Portál AbcLinuxu, 10. května 2025 04:51
16.4.2015 09:15
Max | skóre: 72
| blog: Max_Devaine
Řešení dotazu:
Vypadá to pomale, i když novější verze EF mají mít výkonností vylepšení.V jakém smyslu? Že trvá, než EF vygeneruje SQL dotaz, nebo že vygenerované SQL dotazy jsou neefektivní a ručně by je šlo napsat lépe?
Když se na to dívám okem laika, tak mi přijde, že java 8 má v tomto nemalý náskok.V principu nevidím žádný rozdíl. Co vám přijde tak dobré? Nicméně s typovou bezpečností na tom bude hůře jOOQ, naráží totiž na omezenost Javy – např. na absenci anonymních záznamů, takže následující dotaz
Result<Record3<String, String, String>> result =
create.select(BOOK.TITLE, AUTHOR.FIRST_NAME, AUTHOR.LAST_NAME)
.from(BOOK)
.join(AUTHOR)
.on(BOOK.AUTHOR_ID.equal(AUTHOR.ID))
.where(BOOK.PUBLISHED_IN.equal(1948))
.fetch();
vrací trojice, kde k prvkům přistupujete buď pomocí getValue např.
r.getValue(AUTHOR.FIRST_NAME)Jenže, co když se zeptáte na pole, které není součástí výsledku? Dostanete výjimku
IllegalArgumentException. Proto je tu druhá možnost – přístup přes pozici
r.value2()Jenže, co když někdo například změní pozici autorova jména? Navíc, pokud bude výsledek obsahovat více než 4 sloupce, bude takový kód těžko čitelný. Na druhé straně v C# můžete vytvořit nový anonymní typ
new { BookTitle = ..., AuthorFirstName = ..., AuthorLastName = ... }
a pak jednoduše psát
r.AuthorFirstNamea kód je přehledný a bezpečný (kompilátor zachytí, když napíšete
r.Year, kde Year není součást výsledku).
A to vsechno jenom proto, aby se programatori nemuseli ucit SQL?Obecné výhody nástrojů tohoto typu: Kusy dotazů jde používat opakovaně (fragment dotazu jde použít ve více dotazech), nevzniká problém SQL injection, můžete používat stejný dotaz pro databázi, pro kolekce aj. Jazyky se silnějšími typovými systémy pak umožňují dotazy parametrizovat tabulkami, názvy polí apod. Například můžete vytvořit typově bezpečné administrační rozhraní, které funguje pro libovolnou tabulku. Pak ho použijete:
(* Deklarace tabulky. *)
table t1 : {Id : int, A : int, B : string, C : float, D : bool}
PRIMARY KEY Id
(* Vytvoříme administrační rozhraní pro tabulku t1. *)
open Crud.Make(struct
val tab = t1
(* Titulek stránky. *)
val title = "Crud1"
(* Typy a názvy sloupců. *)
val cols = {A = Crud.int "A",
B = Crud.string "B",
C = Crud.float "C",
D = Crud.bool "D"}
end)
pokud někdo ty dotazy pouští nad kolekcemi, asi nepotřebuje SQL databáziKolekce se hodí třeba v testech. Nebo má data v databázi a pak ještě v nějaké službě přístupná třeba přes OData. Všude může používat stejné dotazy.
Stručně řečeno, tenhle typ ORM nástrojů se hodí tam, kde se jako technologie chybně zvolila SQL databáze.To vůbec nemusí být ORM (sám nejsem příznivcem ORM), zmínil jsem třeba Ur/Web – tam jde primárně o korektnost a redukci kódu. Navíc tam nejsou žádné objekty. SQL je beztypový jazyk a korektnost kódu vám staticky nepohlídá. Rovněž je tam těžké kód použít opakovaně. Proto je vhodnější použít jiný jazyk.
SQL je beztypový jazyk
WHERE sloupec = 5 když typ sloupce je varchar a naopak nejde napsat WHERE sloupec = 'ahoj' když sloupec je číselného typu. Vyhodí to výjimku, tedy pokud pomocí "::" hodnotu nepřetypujete (ovšem musí jít přetypovat že).
V postgresu nejde napsat WHERE sloupec = 5 když typ sloupce je varchar a naopak nejde napsat WHERE sloupec = 'ahoj' když sloupec je číselného typu. Vyhodí to výjimkuDůležité je, kdy se to děje. Jestli se to děje až za běhu SQL skriptu, tak to není typový systém. Podle knihy Types and Programming Languages je typový systém:
A type system is a tractable syntactic method for proving the absence of certain program behaviors by classifying phrases according to the kinds of values they compute. … Another important element in the above definition is its emphasis on classification of terms—syntactic phrases—according to the properties of the values that they will compute when executed. A type system can be regarded as calculating a kind of static approximation to the run-time behaviors of the terms in a program.Typový systém tedy počítá statickou aproximaci chování programu. Např. Python žádný typový systém nemá, neboť před spuštěním programu se tam žádná aproximace jeho chování nepočítá. Nicméně máte pravdu v tom, že některé implementace SQL typovou kontrolu v určitých situacích dělají (např. při kompilaci uložených procedur), nevím však, zda je to součástí standardu?
No nevím, doteď jsem žil v domění že typovost a okamžik vazby jsou dvě rozdílné věciAno, jsou to různé věci. O vazbě jsem nic nepsal.
V tom případě mi přijde, že typový systém ztotožňujete pouze se statickým.Ano, přesně tak.
Důležité je, kdy se to děje. Jestli se to děje až za běhu SQL skriptu, tak to není typový systém.
27.4.2015 10:35
rADOn | skóre: 44
| blog: bloK
| Praha
Když se typy zjišťují před spuštěním operace…Kdysi davno se SQL psalo primo do kodu a nejakej preprocesor z toho vybuildil rovnou kod na strachani se v datovych souborech. Tomu by se dalo rikat "typovy" pacz mohl strilet chyby uz pri kompilaci. Ano, mas pravdu, mysql se obcas chova kokotsky… ale pokud jedinej rozdil je ze ti misto jedny vyjimky vystreli jina, tak to neni silne typovy. To bys stejne mohl rikat ze je silne typovy python - interpret te taky posle do prdele kdyz mu podstrcis „1 + 'foo'“.
ale pokud jedinej rozdil je ze ti misto jedny vyjimky vystreli jina, tak to neni silne typovy.
Myslím, že vůbec nezáleží na tom jestli C# nebo Java. Klíč k výkonosti vidím spíše v pojetí ORM knihovny. Co očekávám od ORM knihovny? Dotazy vrací objekty, které podporují lazy loading a vrácené objekty (pokud mají unikátní klíč) jsou zapisovatelné . Prakticky vypadá lazy loading takto:
Person.addressse transparentně propíše jako
select … from ADDRESS A where A.PERSON_ID = :PERSONIDa vytvoří se nová kolekce objektů adressa a vloží se do atributu Person.address. Zapisovatelnost objetů lze ukázat na příkladě:
Person.name = "pepin";se mi propíše (na požádání nebo na konci transakce) na:
update PERSONS P set NAME='pepin',… where P.ID =…
Pokud má tyto požadavky ORM knihovna splňovat, tak jsou dvě cesty jak takových požadavků dosáhnout:
Nyní se pokusím ukázat k jakým neblahým koncům vede přístup číslo 1. Metody (DAO) objektu (a ani jeho potomci) nemohou přímo přistupovat k vlastním datům(!). Kdyby metody udělaly, tak obejdou lazy loading hook implementovaný v proxy objektu. Veškerá business logika je pak vyšoupnuta do vyšších vrstev do kterých se data kopírují. Touto vlastností se zabije objektový přístup a cesta vede beznadějně k antipaternu anemického modelu. Programátoři si pro kopírování dat ulehčují práci a vznikají knihovny jako Automapper a jim podobné. Architektura je pak ukázkovým příkladem lasagne code a ke všemu se většinou nezadržitelně stává i kódem s Ravioli strukturou. Samotný kód business logiky pak tvoří pouze minoritní část, zbytek kódu je balast. Bezuzdné kopírování dat (deep copy) a vytváření objektů pak dává pěkně zabrat alokátoru paměti a garbage collectoru. Spotřeba paměti stoupá do závratných výšin a operations oddělení posiluje HW 
Další negativa proxy přístupu jsou jen kyselou špičkou na proxy ledovci:
Abych nebyl úplně jednostranný, tak zkritizuji i druhou cestu.
Žádná z výtek k cestě 2, ale nemá vliv na výkonnost a udržovatelnost aplikace. To že se nedá jít cestou code first a jde se cestou model first, já osobně považuji spíše za plus, protože se snáze odchytí pokřivené datové modely. Například teď jsem narazil na jeden projekt s přístupem code first, kde místo vazeb 1:N vytvářeli vazby M:N (s vazební tabulkou), protože jejich (homemade) ORM nepodporovalo vazby 1:N. Přirozeně taková chyba má velmi negativní výkonostní dopad a absence podstatných integritních kontrol v databázi navíc vytváří prostor pro datové chyby, které následně i vznikají. Osobně považuji důslednou kontrolu datového modelu jako velmi účiný a jednoduchý způsob jak zabránit zásadním chybám při analýze a následném vývoji SW. Taková kontrola se u přístupu database first mnohem lépe dělá.
Ale zpět k dotazu C# vs. Java. To jestli se bude psát dotaz jen s pomocí konstrukcí Java 1.4 v Cayenne ( rok 2005 )
SQLTemplate q = new SQLTemplate(Person.class, "select * from PERSON where name ='pepin'"); // SelectQuery q = new SelectQuery(Person.class, ExpressionFactory.Equal(Person.nameProperty,"pepin")); // anti sql injection version List p = ctx.peformQuery(q);
nebo LINQ ( rok 2007 )
var query = from p in person
where (p.name = "pepin")
select p;
nebo ve stylu Java 8 ( rok 2014 )
Person.stream().filter(s-> s.name="pepin");
považuji spíše za kosmetické než revoluční změny vedoucí ke zvýšení výkonu. Klíče k výkonné a udržovatelné aplikaci leží totiž úplně jinde.
Mimochodem, asi jste zaregistrovali, že příklad z Cayenne je nejstarší - circa z roku 2005. Příklad pro Enterprise Objects Framework by byl ještě o 10 let starší, tedy cca z roku 1996(!).
Veškerá business logika je pak vyšoupnuta do vyšších vrstev do kterých se data kopírují. Touto vlastností se zabije objektový přístup a cesta vede beznadějně k antipaternu anemického modelu.Anemický model není antipattern – je velmi přirozené jednotlivé věci oddělit a zvýšit znovupoužitelnost kódu. Naopak splácat vše do jedné třídy je antipattern.
) je pravda.
24.4.2015 12:58
rADOn | skóre: 44
| blog: bloK
| Praha
Když umím sql, nemám problém s orm (které mi může ušetřit dost práce).
24.4.2015 14:28
rADOn | skóre: 44
| blog: bloK
| Praha
27.4.2015 10:48
Max | skóre: 72
| blog: Max_Devaine
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.