[MySQL]Tabel doorzoeken naar verschillende kleuren

[Alpha-sphere]

Ik heb een tabel genaamd tshirts. Hierin staan verschillende tshirts met verschillende kleuren. Dus bijv longsleeve maat L is te krijgen in de kleuren groen, blauw, geel en rood. Longsleeve maat L staat 4 keer in 't zelfde tabel alleen dan elke keer een andere kleur. In totaal zijn er zo'n 200 entry's met verschillende t-shirts met verschillende kleuren. Ik wil graag kunnen opvragen welke kleuren er allemaal zijn.

Ik heb al gekeken in mijn MySQL cookbook maar ik weet niet waar ik precies naar moet zoeken.

[whoami]

Zoeken?
Met een SELECT query en een WHERE clause.

Of in jouw geval SELECT DISTINCT kleur from tshirts.

Maar ik denk dat je beter met een ander datamodel werkt (als je maar 1 tabel hebt).

[ Voor 17% gewijzigd door whoami op 17-11-2004 11:00 ]

[dvvelzen]

select distinct kleur from Tshirts

[dvvelzen]

ik zou hem geen ander model laten nemen !!!

als je niet de functie distinct kan gebruiken hoe wil je hem dan

joins / left outer joins
identifier-columns
etc...

laten gebruiken

[TheLunatic]

Alleen alle verschillende kleuren inderdaad met een

select distinct(kleur) from tshirts

, maar ik denk dat dat niet is wat je bedoeld. Het is handiger als je even een deel van je table laat zien, en een overzicht (tabelvorm) van wat voor output je wilt ...

[whoami]

dvvelzen schreef op woensdag 17 november 2004 @ 11:03:
ik zou hem geen ander model laten nemen !!!

Je zou hem dan maar laten aanklooien met een verkeerd datamodel?
Een datamodel met redundante data in, een datamodel waarin je halsbrekende toeren moet uithalen om de informatie die je wilt op te halen, waarin je inefficiënte queries moet schrijven om de data op te halen, en een datamodel waarin de data ononderhoudbaar is ?

Waarom zou je hem dus geen ander datamodel laten nemen ?

[Alpha-sphere]

TheLunatic schreef op woensdag 17 november 2004 @ 11:05:
Alleen alle verschillende kleuren inderdaad met een

select distinct(kleur) from tshirts

, maar ik denk dat dat niet is wat je bedoeld. Het is handiger als je even een deel van je table laat zien, en een overzicht (tabelvorm) van wat voor output je wilt ...

tshirt_id	soort	maat	kleur
1	longsleeve	L	zwart
2	tshirt	M	groen
3	tshirt	S	blauw
4	longsleeve	XL	paars
5	longsleeve	S	Blauw

Zoals je ziet staat blauw er 2 keer in.

Ik wil de kleuren eruit kunnen halen zodat ik het volgende kan echo-en op een pagina.
zwart
groen
blauw
paars

[whoami]

Dat is omdat je een select * gedaan hebt, en niet select kleur.

DISTINCT returned de unieke rijen in de resultset.
Als je enkel de kleuren selecteerd, zal je enkel de unieke kleuren terugkrijgen.
Selecteer je meerdere velden, dan zal je enkel de unieke combinaties van die velden terugkrijgen.

Maar ik blijf erbij dat je datamodel zwaar sucked, en dat je beter eerst eens iets kunt lezen/leren over normaliseren enzo, en een nieuw en beter datamodel maakt.

[ Voor 22% gewijzigd door whoami op 17-11-2004 11:18 ]

[Alpha-sphere]

whoami schreef op woensdag 17 november 2004 @ 11:17:
Dat is omdat je een select * gedaan hebt, en niet select kleur.

DISTINCT returned de unieke rijen in de resultset.
Als je enkel de kleuren selecteerd, zal je enkel de unieke kleuren terugkrijgen.
Selecteer je meerdere velden, dan zal je enkel de unieke combinaties van die velden terugkrijgen.

Maar ik blijf erbij dat je datamodel zwaar sucked, en dat je beter eerst eens iets kunt lezen/leren over normaliseren enzo, en een nieuw en beter datamodel maakt.

Ik zat er eigenlijk aan te denken om voor kleuren en modellen een apparte tabel te maken en van deze twee waardes een tshirt samen te stellen. Bedoel je met beter datamodel een beter database design? datamodel zegt me niet veel. Ben trouwens nog maar een beginneling met databases maken. So plz go easy on me

[ Voor 11% gewijzigd door Alpha-sphere op 17-11-2004 11:31 ]

[TheRookie]

Is het zo dat alle t-shirts in alle maten in dezelfde kleuren te krijgen zijn ?

Als dat niet zo is heeft een distinct volgens mij weinig zin als je geen where soort='[vul in]' gebruikt, want anders krijg je álle kleuren i.p.v. de kleuren die voor dat soort shirt beschikbaar zijn

[ACM]

whoami schreef op woensdag 17 november 2004 @ 11:17:
Als je enkel de kleuren selecteerd, zal je enkel de unieke kleuren terugkrijgen.
Selecteer je meerdere velden, dan zal je enkel de unieke combinaties van die velden terugkrijgen.

Heb je het zelf geprobeerd?

Als het goed is krijg je juist alle records terug, zolang je geen zaken als distinct gebruikt. Ongeacht of je maar 1 of meerdere kolommen opvraagt.

[ACM]

Alpha-sphere schreef op woensdag 17 november 2004 @ 11:28:
Ik zat er eigenlijk aan te denken om voor kleuren en modellen een apparte tabel te maken en van deze twee waardes een tshirt samen te stellen.

En dat is inderdaad beter genormaliseerd en daardoor meestal een beter datamodel.

Bedoel je met beter datamodel een beter database design? datamodel zegt me niet veel. Ben trouwens nog maar een beginneling met databases maken. So plz go easy on me

Ja, datamodel, databasemodel, databaseontwerp, etc

[whoami]

ACM schreef op woensdag 17 november 2004 @ 11:41:
[...]

Heb je het zelf geprobeerd?

Als het goed is krijg je juist alle records terug, zolang je geen zaken als distinct gebruikt. Ongeacht of je maar 1 of meerdere kolommen opvraagt.

Ik had het dan ook wel over die DISTINCT natuurlijk.

Ik weet ook wel dat, als je geen DISTINCT specifieert, je alles terugkrijgt enzo.

[Nick_S]

Met een beter datamodel wordt er waarschijnlijk iets bedoeld als:

Tabel Kleur
Kleur_ID
Kleur_Naam

Tabel Soort
Soort_ID
Soort_Naam

Tabel Maat
Maat_ID
Maat_Naam

Tabel TShirt
TShirt_ID
TShirt_Naam
TShirt_Omschrijving

Tabel Artikelen (Weet ff geen betere naam te verzinnen)
Artikel_ID
TShirt_ID
Maat_ID
Soort_ID
Kleur_ID

Voor alle verschillende kleuren krijg je dan:
SELECT Kleur_Naam FROM Kleur

Voor alle verschillende artikelen:

SELECT TShirt_Naam, TShirt_Omschrijving, Soort_Naam, Maat_Naam, Kleur_Naam FROM Artikelen, TShirt, Soort, Maat, Kleur WHERE Artikel.TShirt_ID = TShirt.TShirt_ID (en de rest van de tabellen)

Zo heb ik het tenminste op school geleerd.

[ACM]

Gelukkig is er dan de natural join

code:

SELECT ...
FROM
  Artikelen
  NATURAL JOIN TShirt
  NATURAL JOIN Maat
  NATURAL JOIN Soort
  NATURAL JOIN Kleur

En je hoeft al die where-condities niet eens op te geven. Wel is het noodzakelijk dat alle kolommen in Artikelen dezelfde namen hebben als de primary keys waar ze naar verwijzen, anders kan de database niet bepalen welke kolommen van welke tabellen er overeen komen.

[ Voor 7% gewijzigd door ACM op 17-11-2004 12:03 ]

[Nick_S]

NATURAL JOIN ?

Nooit van gehoord? Kijkt deze naar identieke kolom namen of naar gespecificeerde foreign keys? Ander belangrijk punt: is dit specifiek voor een bepaald DBMS of staat dit in de SQL standaard?

[ACM]

't Is onderdeel van de SQL-standaard (ik geloof sinds '92) en kijkt bij mijn weten alleen naar de kolomnamen van de primary key en zoekt die in de target-tabel op. Waarschijnlijk zijn er DBMS-en die ook foreign-keygegevens ervoor kunnen gebruiken.

Natural is overigens een specificatie voor alle join-typen, je kan dus ook een NATURAL LEFT OUTER JOIN definieren

[ATS]

Nick_S schreef op woensdag 17 november 2004 @ 11:47:
Met een beter datamodel wordt er waarschijnlijk iets bedoeld als:

Tabel Kleur
Kleur_ID
Kleur_Naam

Tabel Soort
Soort_ID
Soort_Naam

Tabel Maat
Maat_ID
Maat_Naam
...

Wat schiet je hier mee op? Maat_ID is net zo uniek als Maat_Naam, dus waarom zou je deze indirectie willen gebuiken? Zelfde voor Soort en kleur. In feite is er niet zoveel mis met het model van de TS lijkt me.

[Dido]

ATS schreef op woensdag 17 november 2004 @ 12:38:
Wat schiet je hier mee op? Maat_ID is net zo uniek als Maat_Naam, dus waarom zou je deze indirectie willen gebuiken? Zelfde voor Soort en kleur. In feite is er niet zoveel mis met het model van de TS lijkt me.

Maar als je op een gegeven moment je maatomschrijvingen wilt veranderen (XL wordt EG bijvoorbeeld) moet je op dat moment primary keys aan gaan passen. Dat kan nogal bezwaarlijk zijn.

[Verwijderd]

ATS schreef op woensdag 17 november 2004 @ 12:38:
Wat schiet je hier mee op? Maat_ID is net zo uniek als Maat_Naam, dus waarom zou je deze indirectie willen gebuiken? Zelfde voor Soort en kleur. In feite is er niet zoveel mis met het model van de TS lijkt me.

Stel je wilt de kleuren in meerdere talen gaan opslaan. Dan is Kleur_ID, Kleur_Naam makkelijk uit te breiden naar Kleur_ID,Kleur_NL,Kleur_UK enz.
Ook zoekt het stukken sneller als je op een numeriek veld zoekt dan op varchars.
Tot slot, een 32 bits ID neemt 4 bytes in, een char[8] neemt al twee keer zoveel ruimte in. Je database wordt dus over het algemeen kleiner van het gebruik van dit soort lookup tables.

Dus uniekheid is niet het enige criterium van een goed datamodel.
Een datamodel wat bv als primary keys varchar[40] velden gebruikt is niet al te best maar kan wel uniek zijn

[dvvelzen]

die eerder genoemde tabel structuur is netjes...

houdt er wel rekening bij als je iets m.u.v. wil hebben (bv kleur) dat je dan die


select .....
from artikelen a
join ... on ?.id = a.id
join ... on ?.id = a.id
left outer join kleur on a.id = k.id and k.naam = 'rood'
where k.id is null


gebruikt dat is performance gewijs gezien sneller als een not in sub-select


just to let you know...


gr,
Dennis