SQL - Nybegynner med spørsmål

[Manlulu]

Jeg skal lære meg dette språket her nå, og jeg har noen spørsmål.

Tenkte jeg kan poste de fortløpende etter at jeg får problemer.

 

Om jeg burde ha posta dette et annet sted, så kanskje en moderator kan sende den over? Jeg fant ikke ut hvor jeg kunne poste.

 

 

 

Jeg har en tabell som jeg kaller Country. Derfra har jeg en kolonne som jeg kaller Code. Code er landskoder. Altså det er kun 3 bokstaver i alle (lite relevant til spørsmålet mitt).

 

Jeg vil lage en tabell der, kun med landskoder som inneholder bokstaven 'A'.

 

Så langt har jeg disse kodene:

 

Select * from country where Code like 'A__';

 

Select * from country where Code like 'A%';

Disse kodene gir meg bare landskodene som Begynner på A. Jeg vil ha ut landskodene som har A i seg.

 

Knotete forklart men.. noen som kan hjelpe?

Jeg har nett begynnt med SQL og vil lære dette. Så ikke bare post svar, men forklar

[Dan-Levi]

SELECT *
FROM `country`
WHERE `code` LIKE '%a%'

Du vil bruke % på hver side av bokstaven for å søke i begge retninger av 'a'. Når du søker bare 'a%' får du bare de som begynner på a.

Endret 31. august 2013 av Dan-Levi

[vebbiii]

Når du skriver

 Select * from country where Code like 'A%';

Vil det si at du vil ha et mønster som begynner med A, men inneholder hva som helst etter dette. Men dersom du i stedet skriver

Select * from country where Code like '%A%';

vil det oppnå det du er ute etter.

 

 

Sjekk SQL wildcards her: http://www.w3schools.com/sql/sql_wildcards.asp

[Manlulu]

Ahh supert! Takker!

Jeg kommer helt sikkert med flere spørsmål etter hvert

[quantum]

Om jeg burde ha posta dette et annet sted, så kanskje en moderator kan sende den over? Jeg fant ikke ut hvor jeg kunne poste.

https://www.diskusjon.no/index.php?showforum=233

[Manlulu]

Vi driver med join, left join og right join.

 

Hvordan kan jeg vite når jeg skal bruke hva? Noen som har en enkel forklaring?

[Djn]

Si du har disse to tabellene:

    tblA
keyA | valueA
-----+-------
 1   | abc
 2   | def
 
    tblB
keyB | valueB
-----+-------
 1   | ABC
 3   | GHI

Dette er det du får med left join, right join, og inner join:

mysql> select * from tblA left join tblB on tblA.keyA = tblB.keyB;
+------+--------+------+--------+
| keyA | valueA | keyB | valueB |
+------+--------+------+--------+
|    1 | abc    |    1 | ABC    |
|    2 | def    | NULL | NULL   |
+------+--------+------+--------+

mysql> select * from tblA right join tblB on tblA.keyA = tblB.keyB;
+------+--------+------+--------+
| keyA | valueA | keyB | valueB |
+------+--------+------+--------+
|    1 | abc    |    1 | ABC    |
| NULL | NULL   |    3 | GHI    |
+------+--------+------+--------+
2 rows in set (0.00 sec)

mysql> select * from tblA inner join tblB on tblA.keyA = tblB.keyB;
+------+--------+------+--------+
| keyA | valueA | keyB | valueB |
+------+--------+------+--------+
|    1 | abc    |    1 | ABC    |
+------+--------+------+--------+


EKSEMPEL> select * from tblA full outer join tblB on tblA.keyA = tblB.keyB;
+------+--------+------+--------+
| keyA | valueA | keyB | valueB |
+------+--------+------+--------+
|    1 | abc    |    1 | ABC    |
|    2 | def    | NULL | NULL   |
| NULL | NULL   |    3 | GHI    |
+------+--------+------+--------+
(Ops: MySQL har ikke full outer join.)

Left join betyr "ta med alle fra den venstre tabellen, selv om den ikke har en match i den høyre".

Right join betyr "ta med alle fra den høyre tabellen, selv om den ikke har en match i den venstre".

Inner join betyr "ta bare med de som finnes i begge". Hvis du bare sier "join" er det inner join som blir brukt - i det minste i mySQL. Jeg husker ikke om det er standard eller ikke.

Full outer join er ikke i MySQL, men betyr "ta med alle fra begge tabellene, selv de som ikke har en match".

 

Som du ser på resultatene, fylles de manglende feltene ut med NULL. Det går forsåvidt fint an å klare seg med enten left eller right, siden den eneste forskjellen på dem er rekkefølgen du oppgir tabellene i.

 

Rent praktisk, vel - bruk left join om du vil legge på informasjon hvis den finnes, men uansett beholde alt fra den venstre. Bruk inner join om du bare vil ha ting som er felles for tabellene.

Endret 13. september 2013 av Djn

[Manlulu]

Ahaaaaa hvorfor kan ikke foreleseren forklare det på en slik måte?

Men hva så når man får kilometer med tabeller? Hvordan vet jeg hva som er rett for meg? Eller vil dette bli synlig til mer jeg lærer?

[process]

Foreleser ønsker nok at du skal ha en litt annen tilnærming til stoffet, en hvor koblingen til matematikken (mengdelære/set theory) blir tydeligere, denne tilnærmingen blir viktigere etterhvert. Det er derfor greit å begynne med å forstå enkle konsepter på den måten også.

 

Hvilken JOIN du skal bruke utgår i fra det behovet du måtte ha i hvert enkelt tilfelle. De er ulike operasjoner nettopp for å fylle ulike behov. Behovene kommer som regel fra applikasjonslaget over databasen.

 

Og hva så om du har kilometer med tabeller?

Det er det databaser er til, å lagre, strukturere og indeksere store mengder data.

Endret 13. september 2013 av process

[Djn]

Som process sier - det er helt ettersom hva du vil. Som litt konkrete, men søkte, eksempler:

 

Si du har en tabell med personer, og en tabell med parkeringsplasser. Ikke alle har parkeringsplasser, og ikke alle plasser er delt ut. Hvis du vil ha en liste over alle personer og eventuelt hvilken plass de har (om noen), kan du bruke personer left join plasser. Hvis du derimot vil ha en liste over opptatte plasser (f.eks. for å skrive ut skilt til plassene) kan du bruke personer inner join plasser - og hvis du også vil ha med de ledige plassene (f.eks. for å merke de som ledige) kan du bruke personer right join plasser ... eller plasser left join personer.

[Manlulu]

Ahhh okok tror jeg begynner å forstå mer hvordan man bruker join og hvorfor join er delt opp .

 

Ja satser på at foreleser vet hva han driver med ;p Bare litt dumt at et par svar her gir meg ahaa-opplevelser, mens en forelesning gir meg hæ-what-opplevelser

[process]

Godt eksempel Djn.

 

Det er nok desverre ofte også slik at forelesere er 'fanget' i sitt fagfelt og ikke klarer å formidle ting på en god pedagogisk måte. Dette kan spesielt være et problem i realfag, men samtidig ikke ukjent for andre studieretninger.

 

Det er en god idé å holde forankringen i den relevante matematikken (mengdelære), som er det jeg regner med foreleser har gjort.

 

Dagligdagse eksempler kan gi innsikter, men det er viktigere å forstå grunnprinsippene for å virkelig ha nytte av fagene.

Endret 6. oktober 2013 av process

[Manlulu]

Kan noen prøve <enkelt> å forklare meg CONSTRAINT ?

[Djn]

Generelt betyr det "hvis noen forsøker å sette inn eller endre noe, sjekk at dette stemmer før det lagres i tabellen". Det finnes en del typer - tenkte du på noe bestemt?

 

De vanligste er vel foreign key (som krever litt forklaring), check ("feltet antallReisende må være større enn 0" og slikt), unique (denne kolonnen kan ikke ha samme verdi to steder) og not null (det er ikke lov med NULL i denne kolonnen).

 

 

For å forklare foreign key: Si du skal registrere utbetalte lønninger, og har to tabeller:

Ansatt (Navn, AnsattNR) , og Utbetaling (Kroner, AnsattNR). For å lagre en utbetalt lønning finner du det riktige AnsattNR i Ansatt-tabellen, og setter det inn sammen med et antall kroner i Utbetaling-tabellen.

 

Det vil forsåvidt fungere - men hva hvis det havner en linje i Utbetaling med et AnsattNR som ikke finnes i Ansatt? Det kan være en feil, eller en form for svindel; uansett hadde det vært greit å automatisk sjekke. Den beste måten å gjøre det på er å si noe som

"ALTER TABLE Utbetaling

ADD CONSTRAINT sjekkAnsattFK

FOREIGN KEY (AnsattNR) REFERENCES Ansatt(AnsattNR)"

Det betyr i praksis at hver gang noen forsker å legge til en ny rad i Utbetaling, sjekker databasen at AnsattNR på den nye linjen faktisk finnes i Ansatt.AnsattNR. (Og tilsvarende hvis man prøver å endre en eksisterende linje). Denne begrensningen får navnet sjekkAnsattFK , som vil dukke opp i feilmeldingene den lager og kan brukes for å slette den igjen (med ALTER TABLE Utbetaling DROP FOREIGN KEY sjekkAnsattFK).

 

 

Det er også mulig å sette hva som skal skje hvis du sletter en ansatt eller endrer ansattNR: Default er at du ikke får lov til å slette en ansatt eller endre nummeret hvis det finnes utbetalinger, men du kan endre det ved å legge til en av disse på slutten av ALTER TABLE-kommandoen over:

ON UPDATE CASCADE: Hvis du endrer et ansattNR i Ansatt, oppdater det i alle matchende Utbetalinger også.

ON UPDATE SET NULL: Hvis du endrer et ansattNR i Ansatt, sett AnsattNR for de matchende utbetalingene til NULL.

ON DELETE CASCADE : Hvis du sletter en ansatt, slett også de matchende utbetalingene.

ON DELETE SET NULL: Hvis du sletter en ansatt, behold de matchende utbetalingene men sett ansattNR til NULL.

 

 

Mer generelt er det to hovedpoeng med foreign key: Det er en ekstra sjekk for å passe på at databasen logisk henger sammen, og det er en form for dokumentasjon av hvilke tabeller som er ment å kobles sammen. (Det finnes f.eks. verktøy som kan bruke det til å automatisk tegne kart over databaser.)

Endret 15. oktober 2013 av Djn

[Manlulu]

Jeg tenkte på constraint før keys nå til å begynne med.

 

F.eks: Før når jeg har oppretta en tabell, så har jeg bare skreve:

PRIMARY KEY (kolonne_navn),

FOREIGN KEY (kolonne_navn) REFERENCES Andre_tabellen(kolonne_navn);

 

Nå ska jeg pluttselig skrive:

CONSTRAINT et_nytt_navn_pk PRIMARY KEY (kolonne_navn),

CONSTRAINT et_nytt_navn_fk FOREIGN KEY (kolonne_navn) REFERENCES Andre_tabellen(kolonne_navn);

 

Hva er poenget med dette?

 

Jeg tror jeg er litt stødig på dette med keys.. eller.. jeg var.. før dette kom..

[Djn]

Ah, slik sett. Det er bare en annen måte å skrive det på; hovedfordelen er at du kan velge hvilket navn den får. (Som er kjekt hvis du senere skal fjerne den igjen.)

[Manlulu]

Så du gir primærnøkkel og fremmednøkkel et nytt navn? Hvorfor vil du det?

Et spørsmål til: Hvordan bestemmer du hvilken tabell som skal ha fremmednøkkelen? Hvorfor velger man at tabell_a skal ha en fremmednøkkel som peker mot tabell_b sin primærnøkkel. og ikke omvendt?

[Djn]

Vel, hvis du ikke gir de et navn selv, ender de opp med et autogenerert et. Om det er greit eller ikke kommer an på hva du skal med det senere ... og noen liker å sette sine håndplukkede beskrivende navn på alt.

 

Fremmednøkkelen betyr noe sånt som "dette er en referanse; den fulle informasjonen er i en annen tabell". Hvis du har en kunde-tabell, så er hver rad en kunde, og kundeID blir da en måte å peke på en bestemt kunde. I andre tabeller som skal ha med en kunde men beskriver noe annet (regninger, feilmeldinger, osv) bruker du en kundeID for å si hvilken kundeID det er ... og det blir da en foreign key. (Den er "foreign" fordi den beskriver noe annet enn det tabellen egentlig handler om - du har en tabell med regninger, og så trekker du inn kunder fra utsiden.)

 

En annen måte å lese det på er "har": Hvis Regning har en foreign key Kunde(KundeID), så betyr det at regninger har kunder.

Endret 18. oktober 2013 av Djn

[Manlulu]

Hmm så på to tabeller. Regninger og Kunde, så vil jeg ha foreign key på kunde som refererer til regninger? Og da blir det Kunde har regninger?

[Djn]

Nei - foreign key er på regninger, for å fortelle at den "bruker" kundetabellen. Det blir litt som med, tjah, servere: Du trenger å vite hvilken server du skal hente fra, men serveren trenger ikke nødvendigvis vite om deg.

Endret 18. oktober 2013 av Djn