SQL og cascade

[gamlefilm]

Jeg har et kjapt spørsmål ang SQL og relasjonsdatabaser, som jeg skal prøve å formulere ved hjelp av et lite eksempel.

Ok, la oss si vi har en database med 2 tabeller. En for "Person" med felt for navn, og en tabell for "Hund" med feltene navn og eier_navn.

 

Tanken er at hvis jeg endrer navn i Person-tabellen, så skal navnet også endres hvis det samme navnet er i "Hund"-tabellen.

 

Slik er hvordan jeg trodde det kunne fikses:

 

CREATE TABLE Person(

'navn' varchar

);

 

CREATE TABLE Hund(

'navn' varchar,

'eier_navn' varchar,

PRIMARY KEY ('navn'),

FOREIGN KEY 'eier_navn' REFERENCES Person ('navn') ON UPDATE CASCADE

);

 

Men det funker ikke for meg. Hvis jeg fyller tabellene med noen tuppler og prøver å endre noen i Person-tabllen, så vil ikke eier_navn feltet i Hund-tabellen endres selv om de er like.

 

Er det noen som vet hvordan jeg kan få til dette?

[terjeelde]

Hepp og hei,

 

Med det databasedesignet, hva gjør du hvis to hunde-eiere har samme navn?

 

En bedre måte å gjøre det på kan være f.eks:

 

CREATE TABLE Person (
id	  primary key,
first   varchar( 128 ),
last	varchar( 128 )
);
CREATE TABLE Hund (
id	  primary key,
owner   int references Person( id )
);

 

Altså, du lagrer ikke navnet på Hunde-eieren i Hunde-tabellen, bare i Person-tabellen. Så linker du fra Hund til Eier, via ID.

 

Det både løser problemet med flere eiere med samme navn, og også at du slipper å oppdatere navnet flere steder.

 

Vil du ha en liste over alle hunder og deres eiere, så gjør du f.eks:

 

SELECT p.first, p.last, h.name
FROM
Person AS p,
Hund   AS h
WHERE
h.owner = p.id;

 

Du får da en liste over fornavn og etternavn på eier, same hundenavn.

 

Hvis en eier har to hunder, så får du to linjer, begge med navn på eier, og forskjellig hundenavn.

 

(merk at syntax kan variere noe fra database til database, og SQLen ikke er testet. Jeg prøver mer å illustrere et poeng enn noe annet).

Endret 1. mars 2013 av terjeelde

[gamlefilm]

Ja, nå var det egentlig ikke designet som var så viktig(altså; det er ingen tvil om at det du har skrevet opp er et bedre design). Jeg styrte bare unna en del verdier for å slippe å skrive så mye, og fordi det egentlig ikke har så mye med det jeg lurer på å gjøre. Det jeg lurer på er hvorfor jeg ikke får "ON UPDATE CASCADE" til å fungere slik jeg ønsker

[quantum]

Det er helt riktig alt det du skriver her (terjeelde). Men noen insisterer på å bruke naturlige nøkler, og da blir det sånn. Litt mer reelt hadde det vært å bruke personnummer istedenfor navn som nøkkel og så skullet håndtere at personnummeret endres (noe som faktisk skjer, bare ikke så veldig ofte ...).

 

Spørsmålet til TS blir heller; hvilken database bruker du? Mysql? På Postgresql funker det som du forventer.

Endret 1. mars 2013 av quantum

[terjeelde]

Det jeg lurer på er hvorfor jeg ikke får "ON UPDATE CASCADE" til å fungere slik jeg ønsker

 

Har du litt mer informasjon om hvilke databasesystem du bruker?

 

F.eks støtter ikke MySQL med MyISAM-tabell bruk av foreign key, eller gjorde det ikke sist jeg sjekket.

Endret 1. mars 2013 av terjeelde

[gamlefilm]

Det er et MySQL-dbms ja.

[terjeelde]

Du kan bruke SHOW TABLE STATUS for å se informasjon om hvilke tabelltype/engine det er. Hvis det er MyISAM, så har du svaret. Du kan da bytte til InnoDB, og det burde løse problemet.

 

Hvis du ikke er låst til MySQL, så kan det også være en fordel å vurdere PostgreSQL. Mange synes den er bedre, men MySQL får nok også jobben gjort.

[gamlefilm]

riktig i at det var MyISAM ja. Tror heller jeg ikke får endret det, da det er en server jeg har tilgang til via skolen

[gamlefilm]

dvs, jeg har prøvd å skrive

ALTER TABLE Person ENGINE = InnoDB;

 

men det står fortsatt MyISAM... :S

[quantum]

Kanskje du ikke kan gjøre det der annet enn v. create. Sjekk mysql-manualen - for akkurat den versjonen av mysql du bruker. Eller prøv en create table med engine = InnoDB, og se hva du faktisk får. (En kan jo spørre seg om hvorfor du ikke får noen warning eller feilmelding i sånne tilfeller heller ... )

 

Det er svjv. fullt mulig å sette opp mysql uten støtte for innoDB, men da har den ikke de egenskapene som kreves for å kunne kalles et RDBMS (så hvis det er det skolen din hevder den skal lære deg kan du kreve skolepenga tilbake :o)

[terjeelde]

En kan jo spørre seg om hvorfor du ikke får noen warning eller feilmelding i sånne tilfeller heller ...

 

Sagt litt enkelt, så er dette typisk eksempel på hvorfor jeg ikke bruker MySQL.

 

Quantum har forøvrig helt rett, det enkleste er nok å prøve å sette tabelltype med create table.

 

Tenkte bare jeg skulle legge til at hvis du har data i tabellen, så kan du f.eks endre navn på den, lage den nye tabellen (som InnoDB), og så gjøre SELECT INTO for å fylle den nye, med data fra den gamle. Alt dette står nok forklart i manualen.

 

Ellers finnes det mange gode muligheter til å bytte over til PostgreSQL.

 

Du kan f.eks tilby skolen å sette opp og administrere en, den finnes med installer for windows-platform (og i diverse former for andre platformer også), osv.

 

Det ville ikke overraske meg om det finnes gratistilbud for hosting av databaser, og du kan leie en virtuell server for NOK 20,-/mnd eller så, og sette opp en der.

[quantum]

Quantum har forøvrig helt rett, det enkleste er nok å prøve å sette tabelltype med create table.

hm, ja, grunnen til at jeg skrev det var at jeg er litt usikker på om mysql støtter endring av enginetype på eksisterende tabeller. og grunnen til det igjen er at jeg heller ikke bruker mysql, av veldig mange forskjelige årsaker. en av dem er at man ved bruk av alter table faktisk oppretter en ny tabell hvor data fra den gamle blir kopiert inn. det er selvfølgelig ufattelig upraktisk når det dreier seg om databaser av noe størrelse. men når man nå engang snur alt på hodet ved den minste lille alter table, så kan det jo hende det åpner for å bytte engine-type også i samme slengen.

 

... men det var altså en digresjon :o)

[gamlefilm]

Takk for all hjelp forresten! =)