Nette\Database\Table\ActiveRow::ref() a cizí klíč na neprimární sloupec

Tak v tomto bodě jsem Nette musel vzdát, protože jsem to prostě nedokázal v rozumném čase vyřešit. Nechce se mi ohýbat přes koleno implementaci Doctrine do Nette už proto, že mi ta hromada vrstev přijde vysoce neefektivní pro malé a střední projekty, kór v PHP s jeho „cenou“ za vytvoření instance.

achtan napsal(a):

Rike napsal(a):

Tak v tomto bodě jsem Nette musel vzdát

to ze to NDB nedokaze neznamena ze nemozes pouzit Nette stale mozes pouzit dibi a.i.

No to já právě nevím, zda to dokáže nebo ne. Když jsem pročítal internet, jaký framework je široce preferovaný, tak u Nette stálo, že je to dobrá práce s mizernou dokumentací. A je to bohužel tak. U Zendu se v knížce/dokumentaci dočtu, co jde a nejde a proč. Nehrozí, že uživatele donutí používat InnoDB a pak mu znemožní ho používat pořádně. Tady musím pátrat, ptát se, doufat… Po čase člověk zjistí, že to, co považuje za vlastní chybu, je nakonec „vlastnost“ frameworku. To je hrozně ubíjející. Tak fajn, nahradím to dibi. Co dál je ještě potřeba zaflastrovat ve frameworku, aby vykazoval předpokládanou činnost? Jak říkám to strašně rychle unaví a člověk se raději rozhodne jít cestou vlastní nebo Zendu, který se jeví, že má méně podobných „zákoutí“.

Nechci, aby to znělo jako laciná kritika, na Nette jsem fandil dvěma věcem – ORM (na základě práce Jakuba Vrány) a Latte. A první mě dost zklamala. Tak se z toho budu muset vyspat:-)

Editoval Rike (28. 9. 2012 15:19)

@Rike najprv pises ze:

ta hromada vrstev přijde vysoce neefektivní pro malé a střední projekty

a potom tu vyzdvihujes ZEND wtf?!

Vzaby z neprimarniho klice do jine tabuly na neprimarni klic je prasarna.

hrach napsal(a):

Vzaby z neprimarniho klice do jine tabuly na neprimarni klic je prasarna.

Tady by mě docela zajímalo, z čeho to vyvozuješ…?

HosipLan napsal(a):
Nedovedu si představit soudného člověka, který by preferoval Zend.

Já nepíšu, že preferuju Zend, ale že člověk, co má blbý den a při zkoušení si Nette se střetne zrovna s takovýmhle problémem, prostě půjde dál. A že trh křičí „zkus Zend, má mnohem lepší uplatnění, zejména na nadnárodním trhu“, to je věc, která ho k tomu rozhodnutí dotlačí jen rychleji. K tomu se přidá velmi slušná dokumentace, byť anglická, která třeba v tomto problému hovoří jasně. Ale to není podstatné, podstatné následuje:

HosipLan napsal(a):
Kdo to potřebuje, tak má zkrátka špatně navržené schéma.

Z osobní zkušenosti – vždy, když jsem potřeboval něco takhle obskurního, tak jsem po dvou třech týdnech zjistil, že to dělám špatně. Takže ano, je to prasárna. (Nebo pokud jsi opravdu přesvědčen, že to potřebuješ, možná bys potřeboval jinou (grafovou) databázi).

Alternativní klíč je v relačních databázích normálně definovaná věc, takže asi jeho použití nebude hned chybou v návrhu, že? Krom toho, často člověk pracuje s něčím, co dostává a navrhuje k tomu „pokračování“, příčemž původní strukturu musí zachovat (může být klidně produktem SAPu). Taky se může stát, že musí vytvářet „cross“ tabulku, kdy ID z jedné dané struktury páruje s ID z druhé dané struktury. To jsou všechno situace z praxe.
Jak píšu výše, místo řečech o špatném návrhu mi najděte poučku, podle které se nesmí používat cizí klíč jako odkaz na alternativní klíč. Pokud se smí používat, pak nemá cenu řešit něčí návrhy, ale zařídit, aby to framework umožňoval.

A nenadávejte mi do trollů, dokonce bych řekl, že chci Nette používat, líbí se mi práce DGX, ale přece nebudu otravovat na diskusi s každou věcí, kterou nedokážu z dokumentace vyčíst a domnívám se, že sám chybu nedělám…

Editoval Rike (29. 9. 2012 10:13)

jablon napsal(a):
Alternativní klíč může být definovaná o tom asi žádná, ale pokud se k tomu programátor uchýlí, tak je jistě chybný návrh.

Jak jsem psal, někdy prostě musí. Svět není ideální. Nebude kvůli tomu předělávat firemní SAP.

Pokud, jak píšeš nahoře, využíváš InnoDB pro MySql tak jsi si asi vědom, že alternativním klíčem (tak jak ho využíváš) nevytváříš spojení dvou uzlů ( ve smyslu, že alternativní primární klíč nejsou vlastně v db nějak definovány a nevědí o sobě). Navíc musíš asi celkem náročně kontrolovat unique u alternativního primárního klíče + plus takový klíč vytvářet přes nějakou proceduru (v MySQL fakt zlo) … Jak jsou v tomhle případě zajištěny reference (on delete …, on update …)? Nejsou, tedy zde chyba jako hrom.

Ale ta tabulka s altermativním klíčem může pouze mapovat vztah mezi dvěma tabulkama, které mají unikátní primární klíče, ale navzájem neznají jejich párování.

Mimochodem pro DB je definována nultá normální forma a taky tuto formu nikdo nepoužívá protože praxi je to ukrutná prasečinka …

Tohle je jen teorie ideálního návrhu, jak říkám, v praxi se lze setkat s lecčíms, k čemu se musí přistupovat a řešit.