Versio

[SQL Keys]Delete vraagje

Overzicht Reageren

Jacco Engel

Jacco Engel

27/10/2008 09:49:00
Quote Anchor link
Dames, heren en eenieder die niet in een hokje geplaatst wenst te worden.

ik heb 3 tabellen

Table1
[PK]id
veld1
veld1

Table2
[PK]id
[FK]table1.id
[FK]table3.id

Table3
[PK]id
veld1
veld1

De relaties zoals deze nu staan zijn op dit moment de enige die bestaan.

Nu mijn vraag:

Hoe kan ik een record verwijderen uit table3 als deze niet meer voorkomt in table 2.

Verdere info:
Ik draai op InnoDB

Jacco`

PS:
Krijg nu de volgende melding als ik een FK aan wil maken :
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
SQL-query:

ALTER TABLE plugin_fotoalbum_fotos ADD FOREIGN KEY ( album_id ) REFERENCES plugin_fotoalbum( id ) ON DELETE CASCADE ON UPDATE CASCADE

MySQL retourneerde: Documentatie
#1005 - Can't create table './jacco2/#sql-38d0_fb48.frm' (errno: 150)
Gewijzigd op 01/01/1970 01:00:00 door Jacco Engel
 
PHP hulp

PHP hulp

25/05/2012 18:27:41
Gesponsorde koppelingen:
 
Terence Hersbach

Terence Hersbach

27/10/2008 10:09:00
 
Jacco Engel

Jacco Engel

27/10/2008 10:10:00
Quote Anchor link
Een oplossing voor mijn probleem staat er voor zover ik heb gelezen niet in (En ja heb dat ding al tig keer gelezen :P)

Even over de PS, die is inmiddels opgelost, Relaties en unsigned ints gaan niet samen.
Gewijzigd op 01/01/1970 01:00:00 door Jacco Engel
 
Joren de Wit
Beheerder

Joren de Wit

27/10/2008 10:57:00
Quote Anchor link
Je wilt dus alle records uit tabel3 verwijderen waarvan geen referentie meer aanwezig is in tabel2?

Probeer eens zoiets:
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
DELETE FROM table3
WHERE id NOT IN (
  SELECT table3.id
  FROM table2
)

Natuurlijk wel even de juiste kolomnamen invoegen, want table3.id in de SELECT zal zo problemen opleveren.
 
Jacco Engel

Jacco Engel

27/10/2008 10:58:00
Quote Anchor link
:P. Had eigenlijk gehoopt dat het met keys en een cascade achtige oplossing kon. Deze delete gebruik ik nu namelijk ook en wil van het hele gedoe af.

Weet dat het niet handig is om keys ED achteraf te doen , maar het model is er wel op gebouwd alleen tot voorkort geen innoDB beschikbaar
 
Joren de Wit
Beheerder

Joren de Wit

27/10/2008 11:09:00
Quote Anchor link
Dat zal je niet lukken, de relatie ligt namelijk precies andersom. Mits je de FK's goed ingesteld hebt, zullen alle wijzigingen die je in table1 en table3 aan de records aanbrengt, ook doorgevoerd worden in de FK's in table2.

Een ON DELETE UPDATE zal er dus voor zorgen dat als je een record in table3 verwijdert, alle refererende records uit table2 ook verwijderd zullen worden. Wil je het andersom, dus records uit table3 verwijderen waarnaar geen referentie meer bestaat, dan zul je die query moeten gebruiken.

Je kunt het ook zo zien: records in table3 kunnen prima op zichzelf bestaan, zonder dat er ergens een referentie naar die records is. Maar records in table2 hebben records in andere tabellen nodig om te kunnen bestaan.
 
Jacco Engel

Jacco Engel

27/10/2008 11:11:00
Quote Anchor link
Dus ik zou van de velden in table2 en combined PK moeten maken met een FK in table3 om ON DELETE CASCADE te kunnen laten werken als ik het goed begrijp.
 
Joren de Wit
Beheerder

Joren de Wit

27/10/2008 11:15:00
Quote Anchor link
Nee, dan zou immers de opzet van je database niet meer kloppen. In FK relaties is de ene tabel altijd afhankelijk van de andere tabel, en het is dus onlogisch om in beide tabellen FK's naar elkaar op te nemen...

Je zou je ook eens moeten afvragen of het per se nodig is om die records te verwijderen, wat kan het voor kwaad als die records nog een tijdje in die tabel staan?
 
Jacco Engel

Jacco Engel

27/10/2008 11:17:00
Quote Anchor link
Op het moment dat de rest word verwijderd hebben ze geen doel meer.

Kwaad kan het niet maar je krijgt onnodig veel data in je DB. Nou is dat niet echt schokkend maar wil mn db goed en Crapfree houden
 
Jurgen assaasas

Jurgen assaasas

27/10/2008 11:20:00
Quote Anchor link
Dus je hebt data in je DB gezet voordat je relaties hebt gemaakt? In principe zou het niet eens mogelijk zijn om ongekoppelde data in de database te zetten.
 
Joren de Wit
Beheerder

Joren de Wit

27/10/2008 11:23:00
Quote Anchor link
Quote:
Kwaad kan het niet maar je krijgt onnodig veel data in je DB.
Maar dan voldoet het dus om eens in de zoveel tijd een cleanup scriptje (met die query) te runnen. Gebruik een cron-job om dat bijvoorbeeld eens per week te doen en klaar is kees ;-)

@Jurgen: lees ook even de rest van het topic, dan zie je dat je antwoord niet echt relevant is.
 
Jacco Engel

Jacco Engel

27/10/2008 11:29:00
Quote Anchor link
Ik maak er wel iets creatiefs van. Cronjobs zijn per definitie voor zulk soort dingen niet nodig.

Moet toch wat dingen herschrijven dus zal mn model nog wel een keer onder de loep nemen :P
 
Joren de Wit
Beheerder

Joren de Wit

27/10/2008 11:33:00
Quote Anchor link
Quote:
Cronjobs zijn per definitie voor zulk soort dingen niet nodig.
Ben ik niet met je eens, cron jobs zijn juist geschikt voor het uitvoeren van onderhoudsscripts. Je wilt immers dat die scripts periodiek uitgevoerd worden zonder dat jij er zelf omkijken naar hebt.

En het script waar we het nu over hebben, zou een typisch voorbeeld van zo'n onderhoudsscript zijn...
 
Jacco Engel

Jacco Engel

27/10/2008 11:38:00
Quote Anchor link
Blanche,

Simpele reden dat cron geen oplossing is.

Het gaan om een CMS war inmiddels bij een aantal klanten draait, en dat aantal neemt gestaag toe. Nu ben ik niet van plan om voor elke klant een aparte cron te gaan maken of een systeem te schrijven waarbij dat vanzelf goed gaat.

Ik ben het script nu aan het optimaliseren om er juist zoveel mogelijk "handwerk" (waar in dit geval crons aanmaken onder valt) er uit te halen zodat we het makkelijk en snel kunnen uitrollen.

Sorry had ik mischien iets eerder aan moeten geven maar cron is wat mij betreft geen optie. (en voor de server admin nog minder :P)
 
Joren de Wit
Beheerder

Joren de Wit

27/10/2008 11:40:00
Quote Anchor link
Kijk dan is het al een ander verhaal. Een cron job is dan idd een minder geschikte oplossing ;-)
 
Jacco Engel

Jacco Engel

27/10/2008 11:41:00
Quote Anchor link
Sorry dat had ik even iets eerder moeten vertellen denk ik :P
 



Overzicht Reageren

Get Adobe Flash player