Forklaring på Join og Count

Join bruges til at forbinde tabeller...
Count til at tælle poster i tabeller...

Forbinde tabeller:  Lave relationer imellem tabeller.

Jamen hvordan?? Og hvad bliver resultatet??

Jeg forstår max minus af det her :(

\"select count(*) from tabel \" returnerer én post som indeholder værdien af antallet af poster \"select * from tabel \" ville have returneret.

tabeller har rækker og colloner (rows and columns...) dvs er 2-D. Hvis du tilføjer ny
rækker ELLER col. ELLER begge del fra en 2-D tabel til en anden er det en join!

Hvis du har registreret et kundenummer på hver ordre, så kan du se BÅDE ordre og kunde oplysninger ved at JOIN\'e tabellerne på dette kundenummer:

SELECT Kunder.*, Ordrer.* FROM Kunder INNER JOIN Ordrer ON Kunder.Kunde=Ordrer.Kundenummer;

rune - Den fik jeg vidst fat i nu. Hvordan tæller jeg så den anden vej - Altså nedaf??

Join har jeg ikke forstået.

Afsætter lige lidt flere point, da jeg vidst har mange spørgsmål :))

Count tæller antallet af poster i en tabel...

SELECT Count(*) AS Antal FROM Kunder WHERE Postnummer=4100;

Giver dig ANTALLET af kunder i Ringsted.

proacces - Ligger det samme kundenr så i begge tabeller??

\"..Spidser lige min blyant og sætter mig på skolebænken..\"

der er sjældent brug for at anvende Join

i proaccess eksempel gør man f.eks.

SELECT Kunder.*, Ordrer.* FROM Kunder, Ordrer where Kunder.Kunde=Ordrer.Kundenummer;

Hvilket er mere læsbart.

>disky: JOIN er til at forbinde tabeller, WHERE er til at afgrænse rækker... Den gode gamle diskussion!!!

Hvordan tæller jeg så hvor mange poster jeg har i miin DB??? Er det bare:

SELECT COUNT(*) from kunder ???

ja og resultatet er det samme, og mere læsbart med where


poppe: yep

>poppedreng: Ja, du registrerer alle kundeoplysninger (nummer, navn, adresse m.v.) i en kundetabel, og refererer til denne ved at bruge kundenummeret på din ordre. (altså nøjes du med at oprette en kunde een gang, og har mulighed for at sende kunden flere ordrer, ved at indsætte hans kundenummer i ordretabellen)

>disky: Hvordan vil du så liste ALLE kunder, også dem uden ordrer...  Man kan lige så godt starte med at bruge JOIN konsekvent...

SELECT Kunder.*, Ordrer.* FROM Kunder LEFT JOIN Ordrer ON Kunder.Kunde=Ordrer.Kundenummer;

Ok tror jeg har det nu.

Hvis Runesoft også lige smider et svar, så kan jeg lukke nu :-)

Og tak til alle.

select * from Kunder;

Hvis kunde basen hedder \'Kunder\'

Så kigger du jo kun i 1 base, så who cares about join/where ?

Og den anden jeg nævnte hvis jeg vil se kunder og deres ordre.

Ingen grund til at bruge en komplex join til simple ting vel ?

Det giver dårlig performance

Hmmm !

Jeg tror vi skal starte ved det basale :

1. Data er inddelt som tabeller. Dvs. kolonner med navne henad, og rækker nedad.
2. Med \'select\' kan du udvælge (rektangulære) dele af en tabel. Fx. vil \"SELECT fornavn FROM personer WHERE fornavn=\'Bo\'\" vælge kolonnen fornavn og vise dig x antal rækker indeholdende navnet \'Bo\'.
3. Dersom du havde skrevet \"SELECT count(fornavn) FROM personer WHERE fornavn=\'Bo\'\" ville du få en række med tallet x.
4. Tit har man flere tabeller, fx en persontabel og en stillingstabel, og hvis du nu gerne vil vide hvad alle som hedder \'Bo\' laver skal man bruge join (angives som  \',\' eller inner join i SQL-sytaksen se nedenfor)
5. Nu vil jeg lave SQL- som gerne skulle give mig et svar på hvad alle der hedder Bo laver.
6. \"SELECT fornavn, stilling FROM personer INNER JOIN stilling ON personer.id=stilling.personid WHERE personer.fornavn=\'Bo\'\". Istedet for INNER JOIN ... ON, kan man nøjes med et \',\'.
Altså :
\"SELECT fornavn, stilling FROM personer,stilling WHERE personer.id=stilling.personid AND personer.fornavn=\'Bo\'\".

Denne forespørgsel tager de to tabeller og finder de rækker i tabellerne, hvor feltet personer.id\'s værdi findes som værdi i feltet stilling.personid, og dette er relationen mellem tabellerne. Deraf kan det udledes hvilken stilling denne \'Bo\' har. Dette gentages for alle rækker i tabellen personer.

Slutresultatet bliver så en ny tabel med to kolonner : fornavn, stilling , som angiver alle de stillinger alle dem der hedder Bo har.

Håber det hjælper !







Med \'select\' udvælger

ok, et svar.

Disky-> Jeg er ret sikker på at join har en performance fordel frem for \"where\".

Hmm - join har udførselstid n^2 mens where har udførselstid n

>disky: Det jeg mente var selvfølgelig... Se kunder og eventuelle ordreoplysninger...

DB\'en er (eller skulle ihvertfald gerne være) OPTIMERET til at bruge JOIN\'s ved sammenkædning af tabeller, så det giver ikke ringere performance... (så er det et spørgsmål om dårligt database-design)

ikke i de tests jeg har set udført på en kæmpe base, der var join en lille smule langsommere, få ms på en stor søgning.

Men pyt med det, jeg kan bare ikke lide join da de ikke er særligt læsbare synes jeg.

disky... Med hensyn til kompleksiteten i en join, finder jeg at det ofte hjælper. På den måde får man adskilt sine relationer imellem tabellerne fra sine søgekriterier.

normann: lige netop, altså dårligere performance.

proaccess: den påstand vil jeg gerne se dokumenteret.

Tro mig den base vi testede på var bestemt særdeles godt designet.

Jamen dog hvor i hygger jer :-)

Tak for alle svarene - Har virkeligt tænkt længe over det.

Det med udførselstider tror jeg man skal holde op mod den enkelte database implementering.

selv tak :-)

Held og lykke med opgaven

runesoft: yep, det er nemlig extremt afhængigt af basen.

Jeg vil dog ikke give dig ret i at man for adskilt relationerne. Jeg foretrækker at have dem samlet i en fin gruppe.
Ligesom når man programmerer
Design for sig, kode for sig og database for sig. Ikke noget med kode og design i en blanding som mange asp/php kodere desværre næsten altid gør :(
Man skal holde sig til 3-tier modellen.

runesoft : nej

For en join kræves en dobbeltløkke :
For hvert relationsid i den ene tabel skal du se om der findes et sådant i id i den anden tabel.

For en where er der to muligheder :
enten er betingelsen sand eller falsk - det vil sige et lineært gennemløb vil altid være godt nok

disky: Den sidste fangede jeg ikke helt :-)

>normann: Ja, men er det ikke et lineært gennemløb af tabel1\'s rækker gange tabel2\'s rækker...???

hvor hurtig join og where er afhænger af hvilken base man har, altså om det er oracle,sybase,mysql osv.

Jeg glæder mig til at se proaccess\'es svar på om

where med O(n) stadigvæk er langsommere end join med O(n^2)

Jeg kan overhovedet ikke forstå hvorfor i ævler videre om n og n^2. De gør det samme!
Der er ingen regler for hvorledes de skal være implementeret. Det er helt op til den enkelte producent. Hvis din database har så stor forskel på at udføre de to forespørgsler, vil jeg betegne den som ret ringe.

Jeg arbejder selv mest med MSSQL, og jeg mener at den internt skriver relationer skrevet med where om til join. Derfor tror jeg at join er hurtigst på MSSQL. Jeg kan selvfølgelig godt tage fejl. Microsoft har før forbløffet mig.
Derimod har jeg hørt en lille fugl synge om at Oracle er hurtigst til where.

>disky: Jeg har ikke sagt at JOIN giver BEDRE performance end WHERE... Men derimod at det ikke giver RINGERE performance...

>normann: Hvor har du dine n og n^2 fra??? i følge min \"DATABASE SYSTEMS\" er følgende 4 teoretiske join\'s ens:
  FROM renter r, viewing v WHERE r.rno = v.rno;
  FROM renter r JOIN viewing v ON r.rno = v.rno
  FROM renter JOIN viewing USING rno
  FROM renter NATURAL JOIN viewing

Som runesoft påpeger, så er det den enkelte RDBMS, som afgører hvordan det skal angives, men resultatet bliver det samme...

Jeg tror enten jeg har misforstået noget eller andre har !
O(Join) tilhører n^2
O(Where) tilhører n
Men det er to helt forskellige mekanismer - den ene kan jo ikke erstatte den anden !
De muligheder du nævner proaccess er jo bare syntaktiks sukker for en og samme ting.
Så jeg tror egentlig vi alle er enige når det kommer til stykket

>normann: det vi diskuterer er forskellen mellem at hente data fra to tabeller via følgende 2 syntaxer:

SELECT Kunder.*, Ordrer.* FROM Kunder INNER JOIN Ordrer ON Kunder.Kunde=Ordrer.Kunde;
SELECT Kunder.*, Ordrer.* FROM Kunder, Ordrer WHERE Kunder.Kunde=Ordrer.Kunde;

Som du selv påpeger er dette jo \"bare\" et spørgsmål om syntax, og derfor er der ingen forskel i performance (RDBMS laver selv optimeret \"køreplan\" for queryen, som burde blive ens i begge tilfælde)