NDB join více tabulek a operace nad selection
- kedrigern
- Člen | 102
Zdravím,
mám např. jednoduché schéma DB:
CREATE TABLE
domain
(
id
int(11) NOT NULL AUTO_INCREMENT,
name
varchar(25) NOT NULL,
PRIMARY KEY (id
)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;CREATE TABLE
product
(
id
int(11) NOT NULL AUTO_INCREMENT COMMENT ‚Id‘,
name
varchar(20) NOT NULL COMMENT ‚Admin name‘,
domain_id
int(11) NOT NULL DEFAULT ‚1‘,
PRIMARY KEY (id
),
KEYdomain_id
(domain_id
),
CONSTRAINTproduct_ibfk_1
FOREIGN KEY (domain_id
) REFERENCESdomain
(id
) ON DELETE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
Pokud chci obě tabulky vypsat v NDB, tak pochopitelně použiji konstrukci jako:
$conn->table('product')
->select('product.*');
->select('domain.name AS domain_name');
Což mi dá všechno do jedné struktury a já to mohu krásně vypsat.
Nicméně daná data bych chtěl z různých důvodů i updatovat a to ideálně skrze selection (mám komponentu, která vypisuje tabulku a umí několik jednoduchých handlů s danými daty).
Čili použiji např.:
$row = $selection->get(1);
Což vyhodí chybu:
SQLSTATE[23000]: Integrity constraint violation: 1052 Column ‚id‘ in where clause is ambiguous
Což se stane, protože je voláno wherePrimary, které dosadí primární klíč (popř. sekvenci). Nicméně je to uloženo např. jen jak id. Pokud chci aby, vše fungovalo, tak musím udělat:
$row = $selection
->where($selection->name . '.id =?',1)
->fetch();
Je toto správně? A pokud ano, nebylo by smysluplné doplnit $selection->name do metody getPrimary, aby to fungovalo více out of box? Nebo někde dělám chybu?
- hrach
- Člen | 1838
Jako mas pravdu, je to chyba, ale ne tak zasadni, protoze to zrejme blbe pouzivas. Zkus prosim si projit mou prezentaci: http://public.skrasek.com/…_2012_04_28/
- kedrigern
- Člen | 102
@Caine: Dík.
@hrach: Možná je to neopodstatněná nedůvěra, ale pokud mám natural join, tak mi připadá rozumnější nechat ho udělat už samotnou DB (např. i kvůli abecednímu řazení z druhé tabulky) a nadále s tím pracovat, než to vyzobávat po řádcích. Přecijen je to třeba 1 vs 41 dotazů a natural join nebude trvat nějak dlouho (navíc se nacachuje).
Rozsekáno do tolika tabulek to mám kvůli konzistencí napříč DB, jelikož MySQL neumí globální enum – čili tam mám dost tabulek, které mají jen PK a nějaký string (víceméně).
Prezentaci jsem viděl. Je pravda, že jsem zmatený, jelikož dokumentace (alespoň v době, kdy jsem jí četl) je docela strohá a moc podobné případy nepopisuje.
Mimochodem je někde dokumentace změň v v 2.1? Koukal jsem, že @dev verze mi hází depracted etc. (To jen tak na okraj)
- hrach
- Člen | 1838
Tak jestki mas v tabulce 41 enumu tak ano, asi to bude horsi. Nadruhou stranu kvuli razeni to horsi nebude, protoze je rozdil delat join kvuli indexu a kvuli fetchovani dat. Index je rychly. Na dokumentaci moc nekoukej, doporucuji hlavne to video plus prezentaci, to musis pochopit, bez toho ti ndb bude jen klacek pod nohy.