Noen ord om forening (JOIN)

En forening, eller JOIN som det heter på engelsk, er en rasjonell operator på lik linje som utvelgelse av kolonner eller rader som skal vises. Det er en operasjon på relasjons-databaser som brukes til å koble sammen to eller flere tabeller i en database – igjennom en felles kolonne. Dersom man bruker MySQL og InnoDB vil det som regel være primærnøkkelen og fremmednøkkelen som blir brukt som bindeledd.

Et lite eksempel på hva man kan oppnå med forening.

Jeg har to tabeller. Den ene inneholder personer i et register, den andre inneholder postnummer og poststed. Det jeg vil oppnå er å liste ut alle personer med tilhørende poststed. Tabellene ser slik ut (bruker relasjonell form).

person (person_id, name, zip_code*);
 
postal (zip_code, post_place);

De som er understreket er primærnøkler og * markerer en fremmednøkkel. Dette er hva vi kaller en en-til-mange relasjon. For å hente ut ønsket info kan jeg bruke denne spørringen.

SELECT t1.name, t2.post_place FROM person t1 INNER JOIN postal t2 ON t1.zip_code = t2.zip_code;

Nå som vi har fått unna et kjapt eksempel kan vi gå over til hvilke forskjellige foreningsmetoder vi har og når vi vil bruke de.

De jeg kommer til å gjennomgå er

1. INNER JOIN og NATURAL JOIN
2. LEFT OUTER JOIN
3. RIGHT OUTER JOIN
4. FULL OUTER JOIN
5. CROSS JOIN (noen kjappe ord)

INNER JOIN

INNER JOIN, med LEFT/RIGHT JOIN, er nok den foreningen som kommer til å bli brukt mest. Det er noe som kalles equijoin, og betyr rett og slett at man henter ut informasjonen bundet sammen av to felles verdier i en kolonne/attributt. Kodene ovenfor er et eksempel på denne typen forening.

Det som gjør INNER JOIN forskjellig fra noen OUTER JOIN (som LEFT/RIGHT) er at vi henter kun ut de radene (også kalt «tupler») som har verdier i begge de kolonnene som vi forener om. Om vi viderefører eksemplet ovenfor vil dette si at kun personer med poststed og kun poststedene med personer i seg blir hentet ut. Vi får ikke listet ut alle poststedene som ikke er bebodd av noen medlemmer i person-tabellen vår, og vi får heller ikke listet ut personer som ikke har noe poststed registrert.

Eksempel på INNER JOIN finner har jeg allerede skrevet i toppen av artikkelen.

NATURAL JOIN

NATURAL JOIN er i all basis det samme som en INNER JOIN. Eneste forskjellen er at vi fjerner duplikatkolonner. Vi ser at både postal- og person-tabellene inneholder zip_code kolonnen. Dersom vi henter ut alle felt med en vanlig INNER JOIN vil begge disse hentes ut. Det er naturlig at vi ikke trenger denne informasjonen to ganger. Det er sløsing med dataplass/minnebruk. Dersom vi bruker projeksjon (en relasjonell operator som tillater oss å velge hvilke kolonner vi vil ha ut – f.eks SELECT field1, field2 [...]), er det ikke nødvendig med NATURAL JOIN.

Eksempel på NATURAL JOIN

SELECT * FROM person t1 NATURAL JOIN postal t2 ON t1.zip_code = t2.zip_code;

LEFT OUTER JOIN

Nå har vi beveget oss ut på ytterforening. I motsetning til INNER JOIN vil en LEFT OUTER JOIN favorisere en side av tabellene. Det er fortsatt en såkalt «equijoin». Relatert til det eksemplet vi har brukt tidligere vil det bety at vi kan hente ut alle postkodene uavhengig av om de har personer registrert til seg eller ikke – eller motsatt; alle personer uavhengig om de har registrert postkode.

Her er OUTER et valgfritt nøkkelord i spørringen. LEFT JOIN er såvidt jeg vet det samme som LEFT OUTER JOIN.

Eksempel på LEFT [OUTER] JOIN

Jeg vil hente ut alle personer og dersom de har registrert poststed vil jeg også vise disse.

SELECT t1.name, t2.post_place FROM person t1 LEFT JOIN postal t2 ON t1.zip_code = t2.zip_code;

Du ser her at tabellen person er den tabellen som står etter FROM-nøkkelordet. Dette gjør den til en venstrestilt tabell, og det er den vi favoriserer ved å bruke LEFT JOIN.

RIGHT OUTER JOIN

RIGHT OUTER JOIN er i praksis veldig lik LEFT OUTER JOIN. Eneste forskjellen på disse er hvilken side vi vil favorisere. Vi ser av forrige punkt om LEFT JOIN er det person som blir favorisert. Dersom jeg bruker RIGHT JOIN er det postal-tabellen som blir hovedtabellen. Resultatet vil være en tabell over alle postkoder og tilhørende personer som er registrert. Siden vi ikke grupperer vil vi få flere resultater av samme postkode, da «tuplene» er av forskjellige kombinasjoner (forskjellige personer til samme postkode).

Eksempel på RIGHT [OUTER] JOIN

Jeg vil hente ut alle postkoder og dersom de har registrert personer vil jeg også vise alle disse.

SELECT t1.name, t2.post_place FROM person t1 RIGHT JOIN postal t2 ON t1.zip_code = t2.zip_code;

FULL OUTER JOIN

Siden dette også er en OUTER JOIN kan vi kanskje se for oss hva vi kommer til å få. Dette er en ytterforening som ikke favoriserer noen side. Den kommer til å vise poststeder med og uten personer og personer med og uten poststed.

Eksempel på FULL OUTER JOIN

SELECT t1.name, t2.post_place FROM person t1 FULL OUTER JOIN postal t2 ON t1.zip_code = t2.zip_code;

CROSS JOIN

Denne foreningen er litt anderledes enn de vi har sett på til nå. På norsk kalles dette gjerne kryssprodukt eller kartesisk produkt. Her har vi en forening uten noe nøkkelord som JOIN. Vi bruker rett og slett flere tabeller adskilt av komma etter FROM. Uten noe seleksjon (i praksis WHERE-nøkkelordet) vil dette gi alle mulige kombinasjoner av de to tabellene sammenlagt.

Eksempel på CROSS JOIN

Jeg har en tabell med navn tabell1 som har kun én kolonne; tall. Denne tabellen inneholder følgende data: 1, 2, 3. Jeg har også en tabell til med navn tabell2 som inneholder akkurat samme data.

Dersom jeg da kjører følgende spørring:

SELECT * FROM tabell1, tabell2;

Vil resultatet være følgende:

[ tall | tall ]

[ 1 | 1 ]

[ 1 | 2 ]

[ 1 | 3 ]

[ 2 | 1 ]

[ 2 | 2 ]

[ 2 | 3 ]

[ 3 | 1 ]

[ 3 | 2 ]

[ 3 | 3 ]

Referanser

Jeg er særdeles dårlig på norske uttrykk når det gjelder programmering og lignende. Derfor har jeg fått hjelp av boka [i]Databaser[/i] som er skrevet av Kjell Toft Hansen og Tore Mallaug.

For enkelte er det kanskje ikke greit å vite hvilken INT-type man skal ha til tider. Er det TINYINT jeg vil ha? Eler er det kanskje SMALLINT? Hvor går grensen, hvor store verdier?

I manuelen finner vi denne tabellen, som er en temmelig grei oversikt over hvor store verdier du kan ha på de forskjellige INT-typene

Type	Bytes	Minimum Value	Maximum Value
		(Signed/Unsigned)	(Signed/Unsigned)
TINYINT	1	-128	127
		0	255
SMALLINT	2	-32768	32767
		0	65535
MEDIUMINT	3	-8388608	8388607
		0	16777215
INT	4	-2147483648	2147483647
		0	4294967295
BIGINT	8	-9223372036854775808	9223372036854775807
		0	18446744073709551615

Dette gir en pekepinne på hvilken type man skal bruke på de forskjellige feltene når du lager en tabell. Det er ikke alt for mye optimalisering å hente på å sette feltene til lavest mulig, men som man sier: «Mange bekker små, gjør en stor å».

Uansett tenkte jeg at løsningen måtte være å bruke en subquery, hvor man sjekket at id var i id-ene som ble plukket ut av subqueriet. Nyere versjoner støtter ikke å bruke IN/ALL/ANY/SOME til subqueries i WHERE-clause, så da er løsningen ganske selvsigende.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

SELECT
   GROUP_CONCAT(
      a.id
      ORDER BY a.id DESC
      SEPARATOR ', '
   ) as imploded_idfield
FROM myField a
INNER JOIN
   (
      SELECT id
      FROM myField
      ORDER BY id DESC
      -- [WHERE ... ]
      LIMIT 3
   ) b
ON a.id = b.id

Da har vi alle de imploderte verdiene i imploded_idfield, og kan se ut noe som

“300, 299, 298″

Jeg tenkte det kunne være litt kjekt å fått denne servert i fanget, da den kan komme til nyttighet for noen senere. Dette er nesten samme som da jeg skulle finne motsatte av destinkte verdier.

Så den jeg lagde, ble noe slik som den her:

1
2
3
4
5
6

SELECT 
   COUNT( id ) AS quantity, field_name
FROM table
GROUP BY field_name
ORDER BY quantity DESC
LIMIT 1

Så her er FIELD feltet som du teller opp i, og id er unike id til tabellen. Her vil du få noe resultat som dette:

quantity  - field
1233      - value

Håper dere finner den nyttig.

PS/Tips: Om dere vil ha full statistikk over forskjellige verdier og hvor mange det forekommer av de. Kan være kjekt for statistikk-applikasjoner for å telle forskjellige besøk av forskjellige IP-adresser.

1
2
3
4
5
6
7
8
9
10

SELECT user
FROM users
WHERE ip
   IN (
        SELECT ip
        FROM users
        GROUP BY ip
        HAVING COUNT(ip) > 1
       )
ORDER BY user

Den spørringen der skulle etter all min logiske sans fungere ypperlig. Noe som den egentlig gjør. Det hadde jeg funnet ut, om jeg ikke tabbet meg fullstendig ut på PHP fronten.

Vell, tenkte jeg skulle dele dette med dere. Om dere kommer over samme oppgave. Slik er det altså dere finner motsatte av distinct i MySQL.

Er det av ønske å komplisere spørringen litt, så fant jeg også ut av denne, under prosessen:

1
2
3
4
5
6
7
8

SELECT u.user
FROM users u
   INNER JOIN (SELECT ip
                      FROM users
                      GROUP BY ip
                      HAVING COUNT(ip) > 1) d
   ON u.ip = d.ip
ORDER BY user

Det er flere metoder du kan bruke når du skal søke i en MySQL database. De vanligste metodene er å bruke LIKE() eller MATCH(). Her vil jeg forklare en bruk av MATCH, og så vidt nevne LIKE/RLIKE. MATCH bruker vi i noe som kalles FULLTEXT search. Det betyr at du må ha en FULLTEXT-index i tabellen din.

Dette kan du gjøre eks via CREATE eller ALTER. Når du lager en ny tabell kan du f.eks gjøre slik:

CREATE TABLE table (
   news_id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
   my_title VARCHAR(200),
   my_text TEXT,
   FULLTEXT (my_title, my_text)
);

FULLTEXT skal asignes til de feltene som du vil MATCH skal fungere på.

Så hvordan søker vi?

Si at jeg har mye innhold i tabellen ovenfor som handler om elefanter og blåbær.

Så skal jeg plukke ut de artiklene som inneholder nettopp ordene “elefant” og “blåbær”. Da gjør jeg slik:

SELECT id, my_title,
   MATCH(my_title, my_text)
   AGAINST('elefant blåbær') as relevance
FROM table
  WHERE
     MATCH(my_title, my_text)
     AGAINST('elefant blåbær')
ORDER BY relevance DESC

Her rekner du ut rel som relevanse over hvor mye det stemmer, og vi sorterer etter mest relevante søk, fra størst til minst. Vi velger ut ID, tittel og relevanse.

Det blir ingen videre utgreing av dette, det er selvforklarende.

Kjapt om LIKE()

Her kommer det også litt kjapt om hvordan du kan bruke LIKE. Her er det essensielt med wildcardet % for å matche mot resultat.

Her er det korrekt med eksempelet ovenfor:

SELECT id, my_title
FROM table
WHERE my_text LIKE ('%elefant%blåbær%')
AND my_text RLIKE '[[:< :]]elefant[[:>:]].*[[:< :]]blåbær[[:>:]]'

… Eventuelt utvide med å søke i my_title også!

Redigert – 06.07.07 02:38:

Ser jeg har mangel på forklaring av hva RLIKE gjør, som kan forvirre litt. RLIKE fungerer på samme måte som LIKE gjør, bare at det er med regulære uttrykk. På den måten får du mye større muligheter til hva du skal hente ut, og ikke bare benytte deg av wildcard.