Jak v Nette pracujete s databazi?

andros
Člen | 145
+
0
-

Ahoj, pred několika mesici, jsem se tu ptal v cem pracujete pri praci v Nette.(https://forum.nette.org/…raci-v-nette) Dnes bych chtel mirne navazat a rad bych se vas zeptal: Jak nejradeji pracujete v Nette s databazi ? Pouzivate radeji nějaké ORM (Doctrine,.Nextras), pisete si radeji sami sql dotazy (s vyuzitim treba Dibi), nebo mate nejradeji NDB (Nette DB) ?

Mozna reknete, ze zalezi na projektu (u jednoduchých stranek si bohate vystacime s NDB). Proto mne zajima co mate nejradeji, v cem se Vam pracuje nejlepe.

Diky, ze se i tentokrat podelite.

Altimit
Člen | 82
+
0
-

Aktuálně co mám takový větší projekt napsaný v nette tak využívám základní NDB, ale uvažoval jsem, že přejdu na ORM. Bohužel to teď upadlo, protože jsem neměl čas a nějak náladu to celé překopat.
U dalšího projektu (malinký projekt) se spíše asi hodí NDB. Mně zatím i dokonce vyhovovala.

Pavel Janda
Člen | 977
+
+2
-

@andros Malinké projekty NDBT, malé projekty Dibi nebo LeanMapper (spíš dřív, dávno už nefunguje suport ani development, takže teď Doctrine), středně velké projkety Dotrine, velké projekty Dibi, ještě větší projekty moc klasických relačních databází neřeší, ale pokud, tak Dibi.

esorimer
Člen | 114
+
0
-

Od jisté doby na vše Doctrine. I malé projekty se mohou rozrůst na velké…
Výjimkou jsou nějaké jednorázové jednoúčelové app/tools, pak Nette DB.

filsedla
Člen | 101
+
0
-

@PavelJanda Jaká je výhoda Dibi pro velké projekty? proč Dibi? I pro nové velké projekty? (nikdy jsem Dibi nepoužíval)

Pavel Janda
Člen | 977
+
+2
-

@filsedla Dibi je pouze query builder (Ne ORM, ne ActiveRow) s možností použít fluent interface pro skládání dotazu. Má podporu spousty db driverů a je rychlý.

Jaká je výhoda: Je to rychlá, dobrá a hotová knihovna.
Proč na velké projekty: Protože je to jen simple vrstva, která neřeší žádné mapování na objekty, žádné entity apod. Pokud chceš nějaké custom ORM, tak si ho nad Dibi klidně postavíš (viz „abandoned“ LeanMapper).

Je to prostě děsně simple věc. A tím, jak je simple, je mocná.

Svaťa Šimara
Člen | 98
+
-11
-

@PavelJanda Pokud už píšeš o jednoduché vrstvě, která neřeší nic jiného, tak už docela dlouho existuje rozšíření PDO. Nejspíš bude ještě rychlejší, než dibi.

CZechBoY
Člen | 3608
+
0
-

Já jsem přepisoval projekt z dibi na Nette\Database a udělal jsem špatně. Dibi je určitě lepší než Nette\Database, protože je malá, rychlá a hodně toho umí (umí třeba like oproti Nette\Database). Obě umí fluidní příkazy, akorát Nette\Database láká na automatické spojení tabulek – což je velká výhoda když nepotřebuju nic custom, jinak je to velmi velký problém.

Na druhou stranu pokud chceš ORM (a nechceš si ho dělat sám) tak bych použil Doctrine/Nextras ORM atd. akorát je problém, že se budeš muset učit jak se tam co mapuje.

Editoval CZechBoY (10. 5. 2017 15:32)

Tharos
Člen | 1030
+
0
-

Poslední dobou hodně používám také Doctrine DBAL a jsem s ním vcelku spokojený. Na dibi mi s odstupem času vadí styl zápisu parametrů, kterému nerozumí PhpStorm. Pro něj jsou to pak syntakticky chybná SQLka a odmítá v nich napovídat (při psaní JOINů atp.) a to byl pro mě prostě nepřekonatelný hendikep…

Co se mi na dibi líbilo bylo automatické přetypování dat. Doctrine DBAL nativně vrátí všechno jako string, což je takové blbé… Ale ta konverze se dá z dibi do Doctrine DBAL přeportovat.

Po dopsání si té konverze mi na Doctrine DBAL nic zásadního nechybí a pracuje se s ním dobře, ale kdyby dibi umožnilo syntax, které bude rozumět PhpStorm, klidně bych se k dibi zase vrátil. :)

Doctrine DBAL se aktuálně vyvíjí asi tak, jako dibi… Obě jsou to „hotové“, odlazené knihovny.

Jan Tvrdík
Nette guru | 2595
+
+3
-

Doctrine DBAL se aktuálně vyvíjí asi tak, jako dibi… Obě jsou to „hotové“, odlazené knihovny.

Nesouhlasím, Doctrine DBAL je (AFAIK) na psaní složitějších SQL dotazů dost nepoužitelné. Nemá modifikátory, pro escapování LIKE, názvů sloupců a tabulek. Nemá modifikátory pro skládání dynamických podmínek. Escapování pole integerů je extrémně nepraktické. Neumí bulk insert…

Srovnej třeba Nextras Dbal

$this->connection->query('INSERT INTO %table %values[]', $tableName, $rows);

V doctrine si to AFAIK musíš napsat sám (jestli znáš lepší způsob, tak prosím poraď).

private function bulkInsert(string $tableName, iterable $rows)
{
	$rowsEscaped = [];
	$rowsCount = 0;
	foreach ($rows as $row) {
		$valuesEscaped = [];
		foreach ($row as $value) {
			$valuesEscaped[] = $this->quoteValue($value);
		}

		$rowsEscaped[] = '(' . implode(', ', $valuesEscaped) . ')';
		$rowsCount++;
	}

	$tableNameQuoted = $this->conn->quoteIdentifier($tableName);
	$valuesPart = implode(', ', $rowsEscaped);
	$this->conn->exec("INSERT INTO $tableNameQuoted VALUES $valuesPart");
}


private function quoteValue($value)
{
	if ($value === NULL) {
		return 'NULL';

	} elseif (is_int($value)) {
		return $value;

	} elseif (is_bool($value)) {
		return $this->conn->quote($value, Type::BOOLEAN);

	} else {
		return $this->conn->quote($value, Type::STRING);
	}
}
Tharos
Člen | 1030
+
0
-

@JanTvrdík Rozumím. Trefil ses do slabil Doctrine dobře, právě multiinsert jsem nedávno ručně psal… :) Pro escapování pole integerů se dá použít Connection::PARAM_INT_ARRAY, pokud myslíme stejnou věc.

Žádná zmíněná knihovna za mě není ideální, tím vcelku spokojený chci říct, že mi vyhovuje relativně nejvíc, ale mouchy má.

Pro mě je fakt zásadní ta spolupráce s PhpStormem. U Doctrine je výborná (jde hlavně o „bezmodifikátorový“ styl zápisu parametrů), takže když mám namapovaný data source, píšu dotazy tak, že 90% mi píše IDE: já píšu jen první znaky identifikátorů a pak už jen mačkám enter. A třeba JOINy napíše IDE de facto samo, což je pro mě totální návykovka…

To bych už asi nebyl schopen oželet. Bohužel ale například s dibi jsem částečně musel, protože jeho syntaxi parametrů PhpStorm prostě nerozumí a nefunguje to pak celé moc dobře (pro IDE jsou to pak syntakticky nevalidní SQLka).

Za ideál bych považoval dibi nebo Nextras Dbal doplněný o PhpStormu plugin, který by mu umožnil plně porozumět jejich syntaxi. :) Pak bych po Doctrine DBAL asi ani neštěknul.

smog
Člen | 1
+
0
-

Souhlas (s Dibi). Kdyby jen byl ten PhpStorm plugin… chopi se toho nekdo? :)

Eda
Backer | 220
+
0
-

Já používám Nette Database Table a nad ním postavené vlastní ORM (+ na nějaký spešl věci custom optimalizovaný SQL dotazy). Vlastní ORM sice není vůbec ideální a je vevnitř škaredé, ale aktuálně vyhovuje všem potřebám, má hezké API navenek a navíc ani není prostor vše přepisovat do něčeho jiného. Navíc těch alternativ zas tolik není. Docela se mi líbí Nextras/Orm, ale podle mne to neumí všechno, co potřebuju, a navíc mám trochu strach, že to je jen one-man-show a dopadne to jako s LeanMapperem.

Obecně se mi ale s Nette Database pracuje suprově. Jsem na něj zvyklý už několik let a třeba automatický konstantní počet dotazů nebo pohodlnost nepsaní JOINů je fakt super. Takže ono mne vlastně ani tak extra nic ke změně netlačí. Jen špatný svědomí, že kdybyste někdy viděli, jak to moje legacy-ORM vevnitř vypadá, zděsili byste se… :-D A ještě mne teda trochu nahlodává taková noční můra, že se v Nette Database objeví zase nějakej magickej bug jako posledně (pak to naštěstí magicky opravil Martin Jonáš, za což mu patří velký dík!) a nikdo ho nebude řešit.

Když jsem ještě pracoval pro PHP firmu, tak jsme tam měli vlastní ORM postavený nad Dibi a bylo to taky supr. Ale je to bohužel closed-source, no.

Kdybych teď rozjížděl novej velkej projekt, tak to buď s těžkým srdcem udělám nad Doctrine (z mýho pohledu over engineered moloch, ve kterým se některý na první pohled jednoduchý věci strašně blbě dělají, viz třeba již zmíněný multi insert nebo třeba konstantní počet dotazů…, ale třeba už jsem jen mimo a od doby, co jsem se na něj posledně díval, tak se to nějak výrazně posunulo…), nebo si zanalyzuju, jestli by nešel použít Nextras/ORM a případně zkusil jej. Pokud by to byl miniprojektík, tak si vystačím s Nette Database.

neznamy_uzivatel
Člen | 115
+
+1
-

Dvouletý post, ale třeba bude zajímavé sledovat, jak se to mění :)
Moje „hlasování“ :)

Malinkaté a malé projekty = nějaké orm může být, záleží na osobních preferencích
Zlatá střední cesta = (Nette) Database Explorer, výjmečně ORM, když není potřeba hodně složitých vazeb
Velké projekty = Explorer, NotORM
Extrém = silně optimalizovaný vlastní systém nad PDO.

Asi tomu jen nerozumím :) Ale jak někdo dříve psal, že na velké projekty LeanMapper, tak to si nedokážu představit. Nemám projekt nějak zvlášť gigantický, ale přesto – na několik desítek mil. záznamů v db bych ORM opravdu nepustil. Když člověk optimalizuje něco skutečně většího, (ne pár tisíc řádků ve dvou tabulkách), tak prostě jde o každou ms.

Šaman
Člen | 2632
+
+2
-

Na jednom větším než malém projektu dělám a používám z historických důvodů LeanMapper. Na základní práci bez potřeby optimalizace je super (veškeré CRUD na úrovni entit).

Pak je pár případů, kdy potřebuju vytáhnout data napříč celou databází a výsledek ani není žádná OOP entita. Pak je ale možné napsat si ten dotaz v Dibi a v tu chvíli mám nad výsledkem kompletní kontrolu a navíc podporu fluent zápisu.

Jestli bych použil LM kdyby ten projekt teď začínal a vím co vím – to nevím :) Právě ty chvíle, kdy přestane stačit a najednou píšu SQL… což mi nevrátí entitu, takže nad výsledkem nemohu dál traverzovat, musím si pamatovat že nefunguje mapování sloupců (v OOP části mám userId, v SQL mám user_id) apod. Není to ideální. Ale zase kromě těhle případů je to až návykově jednoduché.

A tím, že jedu přes další vrstvu (to ORM), tak na něj mám navázané logování – veškeré CUD operace se mi logují na úrovni ORM. A při zápisu (vytváření, editování, mazání) jsem na limity ORM zatím nenarazil. Problém jsou jen taková ta školní zadání: Najděte všechna nakladatelství, v jejichž správní radě jsou alespoň dva autoři, kteří vydali mezi roky 1970–1989 knihu s hodnocením více než 80%. :D

S tím si prostě nejlépe poradi čisté SQL.

Editoval Šaman (11. 2. 2019 13:02)

Tharos
Člen | 1030
+
+1
-

Pane jo, vlákno vzkříšené z popela. :) Je zajímavé vidět myšlenkový vývoj v čase, a tak také přispěji svou perspektivou z roku 2019. :)


V praxi používám v podstatě vše, od plain SQL přes jednoduchá ORM (vloni jsem na jedné microsite k velkému úspěchu použil Lean Mapper) až po Doctrine ORM (s tím jsem v kontaktu asi nejvíc). Všechny nástroje mi přijdou ve své podstatě super, jde čistě jen o vhodnosti jejich použití. Tohle jsou zhruba moje současná vodítka:

Velké aplikace™

Nebrat. Vůbec takové aplikace nepsat. Jejich dlouhodobá údržba, refaktoring, to vše je problematické. Snad vždy je lepší řešení rozdělit do menších celků, které se pak spolu zintegrují. A tím nemám na mysli hned architekturu založenou na microservices, těch možností existuje více (klidně stačí jen striktní oddělení bounded contextů).

Aplikace s jednoduchou doménovou logikou

Všemožné microsites, jednorázové weby… Bez obav použiji Lean Mapper, Nette\Database, Nextras\ORM. Upřednostním je před plain SQL, protože mi vyřeší 90 % rutinní práce a jako bonus mi přinesou „entity“ s jasnými properties, takže pak nebudu mít všude samá pole a aplikace bude snažší na údržbu, refaktoring atp.

Aplikace s komplexní doménovou logikou

V mé současné práci jde o různá intranetová řešení. Většinou použiju Doctrine ORM, protože pak budu moci naplno využít OOP, řešenou doménu namodelovat a to bývá často prostě elegantní. Doctrine mi ušetří neskutečně práce s psaním vlastního O/R mapováním a s persistencí. Je dostatečně výkonná a skrz naskrz prověřená. Má svá specifika, která je dobré brát v potaz. Je dobré být kamarádem s DQL a umět při čtení dat skutečně ovlivnit, jakou strategií (tzn. jakými dotazy) se data z úložiště získají. V efektivitě různých strategií mohou být propastné rozdíly (problém N+1, použití indexů…) a bez DQL ta performance často fakt není nic moc.

Aplikace aka reporting, různé exporty…

Nemám nic proti plain SQL, které bych psal asi s použití Doctrine DBAL (nebo Nextras\Dbal?). U Dibi mi vadí, že jeho syntaxi nerozumí PhpStorm.


Mám aplikace, kde se update a konzistence doménových dat řeší pomocí Doctrine ORM, zatímco čtení dat (pro potřeby view, exportů…) probíhá nějak zjednodušeně, třeba i přímým SQL. Funguje to dobře :), napsal bych je tak klidně znovu.

Václav Pávek
Backer | 96
+
0
-

Velké projekty jsem zatím nedělal, ale pokud jde o weby (crud), eshopy (složitější dotazy) nebo informační systémy tak jsem si většinou vystačil s Nette Database. Chyběli mi entity tak jsem se rozhodl pro přechod na Nextras/ORM a nelituji.

Pokud bych chtěl query builder s fluent interface tak bych použil Nextras/Dbal (když už používám Nextras/ORM) nebo Dibi (poslední nasazený projekt z 2014, ale sleduji).

Doctrine je pro mě zatím overkill, ale třeba se to někdy změní.

hrach
Člen | 1834
+
+5
-

Jedině Nextras Orm a na vše. Léty prověřené řešení i komplexní doménovou logiku ;-) :P

Eflyax
Člen | 5
+
+2
-

Za mě jednoznačně LeanMapper. Vyzkoušel jsem si ho na menších i větších aplikacích a jsem s ním opravdu spokojený. Postavil jsem na něm vícejazyčný eshop s tísíce produkty ale i one-page web. Obzvlášť u něj oceňuji výkon. Většina mých zákazníků chce aplikaci hostovat na sdíleném hostingu a taková Doctrine to docela dost zpomalí (samozřejmě na nějaké VPS je to něco jiného).
U Leanmapperu bych snad jen ocenil trochu lepší dokumentaci (na pár místech mi to přišlo takové „neprůhledné“), ale možná někdy pomůžu a přispěju do dokumentace sám ;-)

andros
Člen | 145
+
0
-

Když jsem před dvěma lety zakládal tenhle příspěvek, měl jsem krátkou zkušenost s Nette Database a s Dibi. Pak jsem měl to štěstí, že jsem se dostal na školení Nextras ORM od @DavidMatějka . Od té doby na všechny své projekty používám jedině Nextras ORM. Krátce jsem pracoval i s Doctrine. Na Doctrine se mi zase líbí generování struktury databáze a migrací podle navržené entity. Tohle je v podstatě jedinná věc, která mi u Nextras ORM chybí. Ale i tak je Nextras ORM pro mne vždy jasná volba.

Pokud chcete z Nextras ORM vytěžit maximu, určitě doporučuji nějaké to školení. Já se díky @DavidMatějka naučil například používat pro email v entitě property container.

Felix
Nette Core | 1183
+
0
-

andros napsal(a):

… Na Doctrine se mi zase líbí generování struktury databáze a migrací podle navržené entity. Tohle je v podstatě jedinná věc, která mi u Nextras ORM chybí. Ale i tak je Nextras ORM pro mne vždy jasná volba.

Hodne davno jsem napsal nastroj normgen, ktery nam pomahal generovat entity, mappery a repository. Pak jsem pracoval spis s Doctrine, ale tedka to vypada, ze normgen ⇒ nextras-orm-generator znovu ozil.

https://github.com/…rm-generator

Mrkni a pripadne posli PR.

joe
Člen | 313
+
+2
-

Mně se hrozně fajn pracuje s LeanMapperem (díky @Tharos), líbí se mi syntaxe, i když někdy mám problém rozhodnout jakou přesně vazbu chci použít (ale to je spíš můj problém :-)). A tam kde nestačí, tam si vystačím s Dibi. Zkoušel jsem i jiná ORM, ale zůstal jsem věrný LeanMapperu. A že jde o „one man show“ a teď není tolik aktualizovaný a nemění se tolik, no a? Prostě funguje a tím to pro mě končí :-)

Václav Pávek
Backer | 96
+
0
-

Je někdo ochotný se podělit o ukázkové řešení doménové logiky s využitím query builderu (dibi)?
Kamarád si chce přepsat blog takže se primárně řeší článek + kategorie a tagy.
Osobně bych použil nette/database, ale požadavek je dibi což v rámci vzdělávání chápu, ale nechci jej učit blbosti.

Antarian
Člen | 1
+
0
-

Zalezi jaky mas styl psani dotazu (DBAL vs ORM), zkusenosti a co ocekavas v budoucnu od projektu. Napriklad vysvetlit zacatecnikovi Doctrine Unit of Work, Entity Manager, a pod. muze byt prilis tezky.

Ja ted pracuju na uplne zakladnim CMS pomoci DDD. Pouzivam ‚Uuid‘ jako primarni klic a Nette Database Explorer je z toho spis Exploder.
Nette Database (Core) mi ted vyhovuje se svym temer nativni SQL. Zvolil jsem MySQL. Takze ak zmenim na PostgreSQL, budu muset asi prepsat cely Data layer. Zatim az jedna Class.

Asi bych mel pouzit Doctrine 2 ak chci DBAL, ORM anebo i ODM a support pro Uuid a pozdeji prepnout mezi PostgreSQL a MySQL. Ale rozhodl jsem se skusit i neco jinyho nez Doctrine. A kdyz se rozhodnes aby Doctine Entity a Domain Entity byli dve ruzne veci v projektu tak to veci jen skomplikuje.