Data in één keer verwijderen

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Geoffrey

Geoffrey

15/01/2008 11:55:00
Quote Anchor link
Goedemorgen mensen!

Ik heb een vraag. Is het mogelijk om een veld genaamd 'user_id', uit meerdere tabellen te gelijk te verwijderen? Ik heb namelijk een database met modules en users. En als ik dan een users wil verwijderen, wil ik ook dat alle records met de user_id van de aangeklikte user uit de volledige database verwijderd word.

Alvast bedankt!
 
PHP hulp

PHP hulp

21/05/2024 01:57:06
 
Joren vh

joren vh

15/01/2008 12:01:00
Quote Anchor link
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
<?php
mysql_query("DELETE user_id, id FROM table1, tabel2");
?>


Code niet getest

Probeer het eens en kijk wat het geeft.
 
Joren de Wit

Joren de Wit

15/01/2008 12:02:00
Quote Anchor link
Oplossing: foreign key constraints!

Als jij op een juiste manier door middel van foreign keys de onderlinge relaties tussen je tabellen hebt aangebracht, hoef je hier nooit over na te denken. Afhankelijk van de instellingen worden records automatisch geupdate of verwijderd zodra het record waar ze afhankelijk van zijn verwijderd of gewijzigd wordt.
 
Robert Deiman

Robert Deiman

15/01/2008 12:08:00
Quote Anchor link
@Blanche

Dan moet je wel: "ON DELETE CASCADE" gebruiken toch?
 
Terence Hersbach

Terence Hersbach

15/01/2008 12:11:00
Quote Anchor link
dan nog kan je een acount beter op inactief zetten. Stel dat jij perongeluk een fout maakt met verwijderen, los dat dan maar eens op ;)
 
Geoffrey

Geoffrey

15/01/2008 12:14:00
Quote Anchor link
Dat is ook weer zo. Maar we hebben bijvoorbeeld wel een dagelijkse update. Dus het enige wat verloren zou gaan is de data van die dag.
 
Robert Deiman

Robert Deiman

15/01/2008 12:16:00
Quote Anchor link
@Terence

De rechten voor het wissen moeten natuurlijk ook beperkt zijn aan 1 of een paar mensen.

Ik ben ook voor het inactief zetten overigens, dat kan ja altijd weer ongedaan maken.
 
Geoffrey

Geoffrey

15/01/2008 12:25:00
Quote Anchor link
ik dat het ook inactief word. in ieder geval bedankt voor jullie tijd!
 
Joren de Wit

Joren de Wit

15/01/2008 12:57:00
Quote Anchor link
@Robert: jup, ON DELETE CASCADE is wat je dan zou moeten gebruiken. Maar zoals gezegd zal dit bijna nooit voorkomen, aangezien het niet nodig is om records te verwijderen.

Dat wil natuurlijk nog niet zeggen dat de foreign key constraints overbodig zijn, die zijn namelijk wel van het grooste belang. Zonder die constraints hangt je database namelijk als een los hoopje zand aan elkaar. De kans op corrupte data is levensgroot en dat is niet waar je op zit te wachten.
 
Robert Deiman

Robert Deiman

15/01/2008 13:07:00
Quote Anchor link
Inderdaad, ik gebruik het nu zelf ook (omdat m'n host nog geen pgSQL ondersteunt nog InnoDB) Maar dan moet je bijvoorbeeld ON UPDATE CASCADE gebruiken.
 
Joren de Wit

Joren de Wit

15/01/2008 13:13:00
Quote Anchor link
Dat hangt eigenlijk maar net van de onderlinge relatie af. Als jij wilt dat de foreign key meeverandert als het record waar naar gerefereerd wordt verandert, is dat de juiste instelling.

Maar ik kan me net zo goed een situatie voorstellen waarbij je niet wilt dat het mogelijk is om het bewuste record te updaten als er nog gekoppelde records in de database aanwezig zijn. In zo'n geval zou je dan dus voor ON UPDATE RESTRICT kiezen...
 
Frank -

Frank -

15/01/2008 13:20:00
Quote Anchor link
Je stelt zowel de gewenste ON UPDATE als de ON DELETE in. Alleen wanneer je voor 200% zeker weet dat je CASCADE kunt gebruiken, gebruik je deze ook. In alle andere gevallen is RESTRICT een betere aanpak.

CASCADE geeft namelijk een domino-effect, alles wat via-via aan het ene record is gekoppeld, wordt bijgewerkt of weggegooid. En dat wil nog wel eens hele vervelende gevolgen hebben...

Tip: Verwijder geen data, pas de status aan.

Backups zijn voor noodgevallen, als de server is afgebrand. Daarnaast zijn backups vaak niet betrouwbaar, de data is slechts zeer zelden zo maar terug te zetten. Ik spreek uit ervaring, heb hier bij zeer grote multinationals mee te maken gehad...
 
Robert Deiman

Robert Deiman

15/01/2008 13:52:00
Quote Anchor link
Backups maak ik regelmatig, dus dat is niet zo'n ramp. Maar als je bijvoorbeeld berichten (noem maar wat hoor) aan een userid hebt gekoppeld, en het wordt overgezet naar een ander id, dan moet het inderdaad wel mee wijzigen.
Anders maak je gewoon een nieuw ID aan en heb je niets met cascade te maken. Maar julllie hebben wel een punt dat er goed over nagedacht moet worden voor je het gebruikt.
 
Frank -

Frank -

15/01/2008 14:01:00
Quote Anchor link
Robert_Deiman schreef op 15.01.2008 13:52:
Backups maak ik regelmatig, dus dat is niet zo'n ramp.
Inderdaad, dát is niet zo'n ramp.

Maar, heb je deze backups ook wel eens teruggezet? En dan niet alleen in de situatie van een backup van gisteren, maar ook eentje van een week oud die je moet mixen met data van ná het aanmaken van de backup? Daar zitten vaak de echte problemen.

Het maken (opzetten) van een backup is een eenmalig karweitje en vervolgens het instellen van een cronjob.
 
Robert Deiman

Robert Deiman

15/01/2008 14:10:00
Quote Anchor link
@pgFrank

Het terugzetten valt nog wel mee als de systemen niet al te groot zijn. Momenteel werk ik aan een CMS, waar ook een "restore" functie in gaat komen. Dan kan je een eerdere versie terugzetten. (beetje zelfde idee als Windows systeem herstel)

Op zich valt het wel mee met de data, omdat ik probeer zoveel mogelijk transactions te gebruiken waar meerdere query's nodig zijn om de boel up to date te maken.
Er zal inderdaad wel wat data verloren gaan bij een gewone backup.

Het systeem voor herstel waar we momenteel aan werken (werkt met MySQL en InnoDB, maar wel via de PDO manier) slaat een kopie van voor de wijzigingen op (binnen een Transactie) zodat die terug gezet kunnen worden.
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.