Databázová vrstva pro Nette: dibi, Doctrine, NotORM?

vrana napsal(a):

dakota napsal(a):

	echo $c2c->company->country->name;

Tohle ale přece rozhodně vztah 1:1 není. Více společností bude mít stejný stát, takže při použití JOINu se bude název státu přenášet opakovaně (to sice prakticky zdržovat nebude, ale je dobré si to uvědomit).

Pár dní už jde použít select("company.country.name").

Asi som trochu v tomto prípade ustrelil. Vyskúšal som tieto dotazy čo som uviedol ešte raz.

V druhom prípade kedy som chcel zlepšiť efektivitu pri získaní nazvu firmy (vzťah 1:1), čiže pri

$company_2_category = $db->table('company_2_category')
                ->where("category_id", 55)
                ->where('company.country_id', 2);

$company_2_category->select('company_2_category.company_id, company.id, company.company_name, company.country_id');

foreach ($company_2_category->limit(500) as $c2c) {
        echo $c2c->company_name;
        echo $c2c->company->country->name;
}

by sa vykonali tieto dotazy:

SELECT company_2_category.company_id, company.id, company.company_name, company.country_id
FROM `company_2_category`
INNER JOIN `company` ON `company_2_category`.`company_id` = `company`.`id`
WHERE (`category_id` = 55) AND (company.country_id = 2)
LIMIT 500

SELECT *
FROM `country`
WHERE (`country`.`id` IN (2))

Trochu ma to prekvapilo, asi sa informácia o country_id získala už zo selectu, myslel som si že sa pre zistenie country_id vykoná další dotaz kde bude v IN (500 ids).

Takže efektívne to je. Len asi nemôžem pri tom využiť cache pri nazvoch stlpcov.

Len mi pride v tomto pripade zbytočne to takto komplikovať len preto že Nette\Database\Selector (NotORM) podporuje len takyto JOIN: SELECT ... FROM company_2_category INNER JOIN company ON ... a nie aj v určitých prípadoch SELECT ... FROM company INNER JOIN company_2_category ON ....

Ak nie je ochota alebo potreba rozšíriť syntax o takyto typ JOIN, tak nebudem namietať. Chcel som len ukázať aj iný pohľad.

Syntax select("company.country.name") nemám vyskušanú.

Editoval dakota (5. 1. 2011 14:00)

dakota napsal(a):

Len mi pride v tomto pripade zbytočne to takto komplikovať len preto že Nette\Database\Selector (NotORM) podporuje len takyto JOIN: SELECT ... FROM company_2_category INNER JOIN company ON ... a nie aj v určitých prípadoch SELECT ... FROM company INNER JOIN company_2_category ON ....

Jaký by se pro to používal zápis? NotORM nezná schéma databáze, takže "$table.$column" se musí používat vždycky pro stejnou věc – konkrétně pro odkazovanou tabulku. Takže pro odkazující tabulku by musela vzniknout nějaká jiná syntaxe (třeba "$table:$column"), což nepovažuji za šťastné.

Len asi nemôžem pri tom využiť cache pri nazvoch stlpcov.

To mě taky trápí. Už před delší dobou jsem přemýšlel o tom, že bych povolil syntaxi $row["$table.$column"], ale to by byl bez keše zabiják výkonnosti (protože by se nejdřív musel položit dotaz bez JOINu a pak ještě znovu s JOINem). Navíc to má akademický problém v tom, že název sloupce může obsahovat tečku, ale ten se projevuje i jinde.

Každopádně jsou JOINy něco, co jsem v NotORM nikdy moc nechtěl a jsou tam jen proto, že se s nimi některé věci dělají pohodlněji. Pokud to jde, tak já osobně se bez nich obcházím – výkonnostně se jimi nic zásadního nezíská.

dakota napsal(a):

Bude sa Nette\Database príp. Nette\Database\Selector v blízkej budúcnosti rozširovať o nejaké dalšie metódy, príp. možnosti, nástroje – napr. o niektoré veci z dibi?

Zatím bych nepředbíhal. Nejprve chci dokončit a pořádně si vyzkoušet současnou podobu a pak zvažovat, co dál. Nebude existovat důvod, proč při Nette\Database používat i dibi, ale kterou cestou se vydat zatím váhám.

Je možné konkrétnejšie uviesť aká ďalšia podpora modelu sa popri Nette\Database v Nette pripravuje? V úvodnom príspevku je slabo načrtnuté čo sa v rámci podpory modelu pripravuje.

Cílem je co nejvíce zjednodušit často používané operace CRUD. Tedy víc práce bude mimo Nette\Database.

vrana napsal(a):

Každopádně jsou JOINy něco, co jsem v NotORM nikdy moc nechtěl a jsou tam jen proto, že se s nimi některé věci dělají pohodlněji. Pokud to jde, tak já osobně se bez nich obcházím – výkonnostně se jimi nic zásadního nezíská.

Uvediem malý zjednodušený príklad použitia Nette\Database\Selector v modeli (inšpirované príkladom v Nette\Examples), týka sa problému ktorý som uviedol v predošlých príspevkoch:

class Model extends Object
{

	public static $database;

	public static function companies()
	{
		return self::$database->table('companies');
	}
}

$companies = Model::companies();

$filter = $form->getValues();

if (!empty($filter['country_id'])) {
	$companies->where('company.country_id', $filter['country_id']);
}
if (!empty($filter['company_name'])) {
	$companies->where('company.company_name', $filter['company_name']);
}
if (!empty($filter['city'])) {
	$companies->where('company.city', $filter['city']);
}
if (!empty($filter['category_id'])) {
	$companies-> ???
	// poddotaz ??? a čo ked v danej kategorii je 20000 firiem - problem MySQL
	// INNER JOIN company_2_category ???
}

foreach ($companies->limit(50) as $company) {
	echo $company->company_name.'<br>';
	echo $company->city.'<br>';
	...
}

V uvedenom príklade chcem poukázať na: ak by som sa chcel dotazovať na firmy podľa filtra tak takto jednoducho to v Nette\Database\Selector nepôjde a musím vymyslieť iný spôsob.

Jaký by se pro to používal zápis? NotORM nezná schéma databáze, takže „$table.$column“ se musí používat vždycky pro stejnou věc – konkrétně pro odkazovanou tabulku. Takže pro odkazující tabulku by musela vzniknout nějaká jiná syntaxe (třeba „$table:$column“), což nepovažuji za šťastné.

Napadá ma zaviesť pre tabuľky M:N konvenciu pre názov napr. company_2_category čiže nie company_category – odtial zistiť potrebne cudzie kľúče pre pripojenie.

Edit:

Menná konvencia by možno pomohla v prípade company_2_category, ale nepokryla by všetky odkazujúce tabuľky.

Ďalšie možnosti:

• ponechať „$table.$column“ a riešiť to v DatabaseReflection (v NotORM v Structure) – asi by sa musela definovať určita schéma databázy
• zaviesť nejakú syntax v metodách where a možno aj order a select, buď namiesto . použiť niečo iné alebo zaviesť syntax v názve tabulky zapísanej v metode
• doplniť metódu join – to asi nie ale v nutnom pripade by to pomohlo
• …

Možno niekoho napadne niečo iné.

Nette\Database\Selector (NotORM) v určitých prípadoch značne uľahčuje prácu, sprehľadňuje kód a je aj efektívne. Ja osobne ho používať pravdepodobne budem (namiesto dibi a DibiFluent). Ale v určitých prípadoch prácu pri zostavovaní dotazu skôr pridá na rozdiel od DibiFluent.

Editoval dakota (6. 1. 2011 9:14)

vrana napsal(a):

Já bych neváhal použít (syntaxe NotORM):

$companies->where("id", $db->company_2_category("category_id", $filter['category_id'])->select("company_id"))

Aj vtedy keď dopredu neviem koľko firiem je v danej kategorii? Môže tam byť 1 ale aj niekoľko desiatok tísíc. Čiže v prípade MySQL bude v IN toľko id. S pamäťou by nemal byť až taký problém, načítajú sa len id. Skúšal som to nie je to až také pomalé. Len obava to používať.

Edit 10.1.2011:

Od určitého počtu firiem v danej kategórii (myslené 30000, 40000, 50000 a viac, závisí to od nastavenia memory_limit) môže byť problém s pamäťou (nebude stačiť) pri MySQL (kde je poddotaz v Nette\Database\Selector prekládaný na IN ($ids)).

Editoval dakota (10. 1. 2011 17:11)

dakota napsal(a):

Napr. v DibiFluent je to riešené ako SELECT COUNT(*) FROM ( vytvorený dotaz ) as data …

Takýto select je v prípade MySQL pomalý… Viď https://forum.dibiphp.com/…urce-a-mysql

Jak by se dal zapsat dotaz z příkladového schématu application .. aplikace nějakého autora, které nemají tag?

pokoušel jsem se to takto ale vygenerovaný dotaz je špatný v tomto joinu:

<?php
INNER JOIN application_tag ON application.application_tag_id = application_tag.id
?>

kde si volí špatné názvy – application.application_tag_id = application_tag.id

<?php
$db->application()->where('author.born <= "1950-01-01"')->where('application_tag.tag_id = NULL')
?>

<?php
SELECT application.* FROM application INNER JOIN author ON application.author_id = author.id INNER JOIN application_tag ON application.application_tag_id = application_tag.id AND (author.born <= '1950-01-01') AND (application_tag.tag_id = NULL)
?>

Oggy napsal(a):

JOINy typu INNER JOIN application_tag ON …, LEFT JOIN application_tag ON … nie sú v Nette\Database\Selector podporované.

Myslím, že by sa dalo použiť:

$apps = $db->table('application')
	->where('author.born <= "1950-01-01"')
	->where('application.id NOT', $db->table('application_tag')->select('application_id'));
	// application.id NOT IN (...)

Nemám to však vyskúšané.

Editoval dakota (9. 1. 2011 12:54)

vaclav napsal(a):

U mňa to funguje v poriadku, neviem o akú reviziu Nette Framework 2.0-dev ide, treba skúsiť najnovšiu.
V Nette\Database\Selector som chybu s IS NULL vo where neobjavil.
Nette Framework 2.0-dev, revízia c1c9de0 released on 2011–01–07.

Funguje to takto:

->where('contact_person_id', NULL);
->where('contact_person_id IS NULL');
// WHERE (`contact_person_id` IS NULL)

Editoval dakota (10. 1. 2011 16:22)

děkuju :-)

ještě mám spíš takovou prkotinu ..

do šablony si předám z databázového dotazu nějaké záznamy, říkejme jim $entries.

a pak je řádím do různých skupinek a uvádím počet záznamů.

tzn.

<?php
today: {=$entries->where('date = CURDATE()')->count('*')}
tomorrow: {$entries->->where('date = CURDATE()+1')->count('*')}
atd ...
?>

tak NOTORM genereuje dotazy, které se na sebe nabalují.. takže vlastně ke každému výše uvedenému řádku vezme předchozí dotaz a přidá další podmínky.

cesta, která mě napadla, je si před každým dotazem uložit původní entries do jiné proměné a každý jednotlivý dotaz pokládat nad těmi „čistými“ (původndími) entries .. ale děje se to samé ..

<?php
{var today => $entries}
today: {=$today->where('date = CURDATE()')->count('*')}
{var tomorrow => $entries}
tomorrow: {$tomorrow->->where('date = CURDATE()+1')->count('*')}
?>

jak to elegantně vyřešit ? :-)

Měl bych dotaz, jak využít tečkovou notaci.

Schéma (* jsou FK):

• Tabulka člověk: id, jmeno, clovek_typ_id * – tabulka lidí
• Tabulka clovek_typ: id, jmeno – nějaká skupina, třeba žid, křesťan, ateista, budhista, šintoista
• Tabulka viewparam: clovek_typ_id ,* view_id * – obsahuje „připravené pohledy“- např budhista+šintoista
• Tabulka view: id, jmeno – obsahuje názvy pohledů, v příkladu nebude použita

Mám vstupní hodnotu view_id – budou se tedy zobrazovat např židé a křesťané.
Lámu si hlavu s tím, jak to zapsat (plus půlhodiny hledání, proč to nefunguje )
elegantněji.

zde je můj mezi výsledek: (hlavně ty opakované naázvy se mi nelíbí)
$cond=$db->table("viewparam")->where("viewparam.view_id",$view);$db->table("clovek")->where('clovek_typ_id',$cond->select('clovek_typ_id'))

Psalo se zde:

/---quote
Pár dní už jde použít select(„company.country.name“).
\--

Jde to použít přímo v dotazu nebo až v iteraci?

Jak by šel daný dotaz zapsat?

Šlo by to nějak takhle:?

$cond=$db->table("viewparam")->where("viewparam.view_id",$view);
$cond->select('clovek_typ.clovek.jmeno');

nebo

$db->table('clovek')->where('clovek_typ',$cond);

Editoval bojovyletoun (17. 1. 2011 1:58)

Nemělo by se tohle vlákno zamknout? Poradna jak co napsat v NotORMu přece nepatří do diskuze o vývoji frameworku. Berte ohledy na ty, kdo maj v RSS jen tuhle sekci ;)

Honza Marek napsal(a):

Nemělo by se tohle vlákno zamknout? Poradna jak co napsat v NotORMu přece nepatří do diskuze o vývoji frameworku. Berte ohledy na ty, kdo maj v RSS jen tuhle sekci ;)

Jsem pro. Oni sem lidi asi píšou proto, že na to tady odpovídám. Tak mě pak jen pošlete na nové místo.