Dotaz: SQL - výběr dat z databáze : join+group by nebo něco jiného?

[skorSQL]

Ahoj. Mám v mysql tři tabulky. V první jsou uživatelé s jednoznačným id. V druhé skupiny s jednoznačným id. Ve třetí přiřazuji skupiny vs. uživatele. Řekněme že potřebuju vypsat všechny uživatele, které se nacházejí ve skupině XY. Standardně bych to asi řešil tak, že bych nad tabulkama vytvořil pohled - v něm by se pak zobrazovala všechna uživ. jména třeba několikrát s různými skupinami a potom v aplikaci bych udělal "group by username". Mám ale takové tušení, že to není správný a nejrychlejší (ačkoliv funkční) postup. Je to tak? Co jiného bych měl použít?

Odpovědi

[jekub]

Jak se můžou při dotazu na konkrétní skupinu XY zobrazovat "uživ. jména třeba několikrát s různými skupinami"?

[skorSQL]

Proč ne pokud použiju v pohledu inner join.

[jekub]

Pišete, že máte v tabulce uživatelů unikátní id (uid) a v tabulce skupin taky unikátní id (gid). Předpokládám, že ve vazební tabulce uživatel <-> skupina máte unikátni (uid, gid).

Potom při dotazu na konkretní skupinu nemůžete získat uživatele s různými skupinami. Prostě dostanete seznam uživatelů v dané skupině (ano uživatel může být ve více skupinách, to ale na věci nic nemění).

Pokud nemáte unikátní (uid,gid) ve vazební tabulce, je vhodné to napravit. Pokud to není možné, použijte v dotazu distinct na uživatele.

[skorSQL]

To souhlasí. Všechny indexy mám správně. Asi si nerozumíme:

skupina1: user1
skupina2: user1, user2
skupina3: user1

potom budou data selectu z pohledu vypadat takto:
user1 skupina1
user1 skupina2
user1 skupina3
user2 skupina2

[wamba]

to je v pořádku, ne? nebo jak by jste si ten výstup představoval?

[Filip Jirsák]

Já bych to tedy řešil těmi nejzákladnějšími prostředky, které SQL má, tedy

SELECT uzivatel.* FROM uzivatel, uzivatel_skupina WHERE uzivatel.id = uzivatel_skupina.uzivatel_id AND uzivatel_skupina.skupina_id = ?

Případně si z toho můžete udělat pohled a tu druhou podmínku z WHERE používat až nad tím pohledem.

[jos]

no fuj, tenhle způsob joinu zdá se mi poněkud nešťastný

[Filip Jirsák]

Co je na něm nešťastného? To je obyčejný JOIN, základ všech relačních databází.

[jos]

špatně se to čte, musim se prokousat až na konec, abych zjistil že se nejedná o CROSS JOIN

pokud čitelnost zdrojáků dostává na prdel, tak je to IMHO vždy nešťastný

jo a pokud nějaká relační databáze neimplementuje JOIN tak to podle tebe není relační databáze? jen polemizuju do jaký míry je JOIN základ

[Filip Jirsák]

Aha, takže vám jde jen o způsob zápisu toho JOINu. To záleží na vkusu, já zase nemám rád zápis s klíčovým slovem JOIN, protože při spojení tří a více tabulek nějak nikde nevidím levou a pravou tabulku

Relační databáze je podle mne relační právě proto, že jsou v ní vyjádřené vztahy (relace) mezi entitami. K jejich získávání je pak samozřejmě potřeba spojení tabulek (JOIN). Pokud nějaká databáze neimplementuje JOIN, může to být objektová databáze, síťová, mapa, ale ne relační databáze.

[jos]

proti gustu ...

relační databáze je relační, protože obsahuje relace (tabulky, pohledy, table valued funkce ...), nikoliv protože jsou v ní vyjádřené vztahy

od jisté doby proti tomu mýtu okolo významu pojmu "relační databáze" bojuju - třeba zde

[Filip Jirsák]

Jaký je rozdíl mezi relací a vztahem?

[jos]

žádnej

ten "vztah" je mezi jednotlivejma hodnotama v jednom řádku tabulky, proto se říká "relační databáze", ne kvůli tomu že si řeknu, že nějakej sloupec odkazuje na jinej sloupec (a třeba v jiný tabulce), případně to ještě podtrhnu nějakým constraintem

lidi si bohužel často tohle neuvědomujou, C. J. Date doporučuje v angličtině pro mezitabulkový (ehm) vztahy používat slovo "relationship"

[Filip Jirsák]

Opravdu je důležité, zda ten vztah je vyjádřen v jedné tabulce nebo ve více? Vztahy 1:1 můžu libovolně mezi „relation“ a „relationship“ převádět, vztahy 1:N nebo M:N nejde bez „relationship“ vyjádřit vůbec… Navíc při takovémhle pojetí by třeba objektové databáze byly podmnožinou relačních. Jak by se pak říkalo té podmnožině relačních databází, která data uspořádává do tabulek a umožňuje vyjádřit M:N vztahy mezi daty (tedy tomu, co se běžně nazývá relačními databázemi)?

[jos]

Opravdu je důležité, zda ten vztah je vyjádřen v jedné tabulce nebo ve více?

ale vůbec ne, zdá se, že to písemně nedokážu vysvětlit, zkusim to ještě jednou:

CREATE DATABASE omg;
CREATE TABLE wtf (id INT NOT NULL); --na pk kašlu, pro teď to není důležitý

tim se vytvoří databáze s právě jednou relací (tabulkou)

ta databáze je relační, protože obsahuje relaci (tabulku)

CREATE VIEW lol AS SELECT id FROM wtf

stále máme relační databázi, která teď obsahuje právě dvě relace (jednu tabulku a jeden pohled)

jestli to není jasný ani teď, tak mi nezbejvá než odkázat na http://en.wikipedia.org/wiki/Relational_database

[Filip Jirsák]

Mně se právě nezdá to, že by v relační databázi byla důležitá ta technická podstata (tabulka nebo pohled), a data byla až druhotná. Chápal jsem to tak, že důležité jsou vztahy mezi daty, a to, jestli je ten vztah vyjádřen jednou tabulkou, dvěma, nebo třeba pohledem, je druhotné. Chápu vaše pojetí, ale nepřipadá mi takové vymezení relačních databází jako užitečné, protože pak zahrnuje kde co…

[jos]

to není moje pojetí

The term relational database was originally defined and coined by Edgar Codd at IBM Almaden Research Center in 1970.

když už sme se teď shodli na tom o čem mluvíme, tak na závěr přidam jedno malý překvapení: SQL (resp. libovolnej současnej pokus o implementaci ANSI SQL) není relační databáze! protože v každý se najde nějaký omezení, díky kterýmu se to dá prohlásit

např. při vkládání dat do pohledu (protože relace jako relace) většina produktů selhává, a to dokonce i v situaci, kdy z constraintů nad zůčastněnejma tabulema je naprosto jasný jak by se vkládaný data měly rozdistribuovat

u nás (MSSQL 2005) toto ne moc pohodlně řešíme INSTEAD OF <whatever> triggerama, což má zase za důsledek další omezení - třeba OUTPUT klauzule nefunguje atp.

C. J. Date napsal na tohle téma mraky materiálu, stačí googlit nebo navštívit nějakou dobrou knihovnu

[Tarmaq]

SELECT 
    u.id,
    u.username
FROM users u
INNER JOIN user2group u2g ON u2g.user = u.id
WHERE u2g.group = <dana_skupina>

Jinak pokud jsou uzivatelska jmena unikatni, nemohou byt rovnou pouzita jako primarni klic? Pak by totiz stacilo:

SELECT username
FROM user2group
WHERE group = <dana_skupina>

[skorSQL]

No já bych chtěl aby se to tvářilo jako tabulka transparentní pro aplikaci. Takže view. Ale jak ho vytvořit. Aby to bylo transparentní, tak by to mělo vracet vždy jedno uživatelské jméno. Pokud provedu "where skupina = skupina" nad pohledem, tak by to mělo vrátit uživatele z té skupiny. Pokud to neomezím, tak by to mělo vrátit všechny uživatele, ale pouze jednou.

[Filip Jirsák]

Asi by bylo vhodné dát sem příklad nějakého vstupu a očekávaných výstupů. Mně přestává být jasné, co vlastně chcete získat.

[kulik]

pro odstraneni duplicit se pouziva "distinct"

[Tarmaq]

Co to je "tabulka transparentni pro aplikaci"? Co to znamena "Vracet vzdy jedno uzivatelske jmeno?" Jak to muze v"ratit vsechny uzivatele ale pouze jednou", to snad nemuze byt uzivatel ve vice skupinach? Jsem z toho zadani stejne jako Filip Jirsak lehce zmaten - prosim o doplneni.

[skorSQL]

Mělo by se to chovat jako inteligentní tabulka. Pokud nezadám "where group=" tak by se měli zobrazit všichi uživatelé, ale jen jednou, pokud zadám skupinu(či skupiny), tak by se měly zobrazit uživatelé v té dané skupině

[Filip Jirsák]

SELECT DISTINCT uzivatel.* FROM uzivatel, uzivatel_skupina WHERE uzivatel.id = uzivatel_skupina.uzivatel_id AND uzivatel_skupina.skupina_id IN (?)

[Tarmaq]

Pokud nezadám "where group=" tak by se měli zobrazit všichi uživatelé, ale jen jednou

Kdyz bude uzivatel ve dvou skupinach, ma se tedy ve sloupci se skupinou zobrazit jen jedna z nich? Ktera? Nebude jednodussi v takovem pripade selectit primo s tabulky s uzivateli, kdyz vas skupiny v takovem pripade nezajimaji?

SELECT
   id
FROM users
WHERE id IN (
    SELECT user
    FROM user2group
    WHERE group = ?
);

Tzn. tu podminku where group= nahradit touto a chova se to presne jak potrebujete ;]

[jekub]

Vytvořte si ten pohled (nemusí to být nutně pohled v takto jednoduchém případě) se dvěma sloupci uid,gid a podmínku na skupinu dáte do dotazu nad tím pohledem

select uid from view_u2g where gid='...'

Tak dostanete uživatele v dané skupině. Uživatele v ruzných skupinách pak třeba přes operátor "in" s použitím "distinct"

select distinct uid from view_u2g where gid in('gid1','gid2',...)