foreign key og normalisering

+ da myspl ikke understøtter foreign keys, kan man så overhovedet tale om en relationsdatabase, hvis relationerne kun laves gennem forspørgelser og ikke i databasestrukturen?

hmm - der er understøttelse af foreign key - der er bare ikke constraints understøttelse (cascading deletes f.eks.) - men det kan vel altid betale sig at normalisere til 3. normal niveau (som mere eller mindre svarer til Boyce-Codd)

BCNF adresserer 3NF i de tilfælde hvor kandidatnøglen er sammensat og der er overlap mellem de sammensatte nøgler. I de fleste tilfælde reducereres denne blot til 3nf.

og referentiel integritet en del af mysql hvis du bruger de korrekte databaser (innoDB) samt en del af mysql 4 som skulle blive frigivet "snart" :-)

http://www.mysql.com/doc/en/SEC448.html

>>mfalck
du siger at "der er understøttelse af foreign key - der er bare ikke constraints understøttelse "
jeg er ikke helt sikker på hvad du mener, jeg er ret ny i området. men grunden til jeg spørger er at hvis jeg fx laver en tabel med en "foreign key ( bilID ) references bil,"  så er den pist væk hvis jeg går under "eksport strukturen" det re kun min primære nøgle der kan ses her. derfor kan jeg ikke se hvordan der er understøttlese for foreign key hvis myspl bare ignorere den?

det var vist også noget vås ... som jeg skrev senere så er der kun understøttelse af fremmednøgler med InnoDB og ver 4.

men det er vel alment kendt at hvis du skal have en "rigtig" database så er mysql ikke god nok - så skal du bruge postfix

" en "rigtig" database så er mysql ikke god nok "
ja sådan har jeg også forstået det, og det er netop derfor jeg undrer mig om om der er en sammenhænf mellem normaliseringeni myspl, og manglende understøttelse af foreign keys. ikke mindst da normaliseringen vel altandet lige bevirker mere beregningstid for systemet?

Postfix er ganske rigtigt et udmærket alternativ - til sendmail.
Mon ikke du mener PostgreSQL? ;-)
Ellers er det i hvert fald den første MTA med understøttelse af foreign keys. ;-)

dough - man skal prøve at adskille i hovedet det man arbejder med og det man forsøger at skrive på skærmen :-)

det jeg finder underligt er under 2NF som man jo ikke KAN overholde i Mysql

"Create relationships between these new tables and their predecessors through the use of foreign keys"
kilde http://databases.about.com/library/weekly/aa090201a.htm?terms=Normalization+

Det er jo noget vrøvl. Fordi mySQL ikke håndhæver foreign keys (i nuværende stable), kan du da sagtens normalisere din database i mySQL til 3. normalform (eller videre).

Du må sørge for, at det sprog du interfacer til databasen med, sørger for at opretholde dens integritet (det være sig Java, C whatever). (Eg. slette fra tabel B (der har fremmednøgle med ref. til nøgle i tabel A) når du sletter fra tabel A osv.).

>>mercur8
ok så dvs. når man arbejder i mysql, skal denne del af normaliseringen opretholdes af interface delen(fx gennem php). hvorimod hvis det er en "rigtig" database (ikke mysql)  kan man lave denne del af normaliseringen i selve databaselaget gennem foreign keys.
er det rigtigt forstået?

Normalisering er jo foretaget i dit database design alene. Distribution af data i forskellige relationer, relevante nøgler osv.

Man kan sige, at du gennem interfacesproget opretholder og håndhæver integriteten (normaliseringen).

Ja, det var vist også nogenlunde, hvad du skrev :)

ok nu begynder jge så små at forstå:-)  eks: hvis jeg har 4 tabellre der er kaskade afhængige(mener jeg det hedder). A-D hvor A er afhængig af B som er afhæning af C osv gennem primærenøgler der eksistree som "fremmednøgler" i næste tabel. i mysql vil jeg i interfacet kun kunne få sammengængen i a fra tabelA med d i tabel D, ved at sige "SELECT A.a, D.d form A,B,C,D WHERE A.a=B.a AND .......C.d=D.d.  fordi jeg ikke har "rigtige" foreign keys. der forbinder tabellerne.
hvis jeg havde mulighed for at bruge rigtige foreign keys, hvad ville jeg så have af fordel her?

Er der i øvrigt nogen der vil have pionts for denne glimrende tråd?

Om du har foreign keys eller bare almindelige nøgler giver i forbindelse med din SELECT ingen forskel.

øh ok, i hvilken slags forspørgelse er det så jeg har fordele af foreign keys ?

Ved modifikation af de indeholdt data (eg. UPDATE, INSERT, DELETE). Foregin keys er et værktøj til at opretholde den referentielle integritet. Hvilken du i mySQL ikke har til rådighed, men selv må sørge for at opretholde (typisk gennem det sprog du interfacer til databasen med).

"Det sprog du interfacer til databasen med" : Lidt misvisende. For dette sprog er jo som bekendt SQL. Så i stedet: "Et niveau højere end databasen".

AHA. så foreign keys sikre mig at hvis jeg ændre en post i eksemplet fra før, vil det påvirke kaskaden af tabeller og ikke kun den tabel jeg retter i. men i Mysql er jeg nød til at sikre denne sammenhæng i et lag højere end databasen.

rigtigt forstået?

Ja.

endelig faldt 10 øren:-)  tak for det!