Data in één keer verwijderen
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!
Code niet getest
Probeer het eens en kijk wat het geeft.
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.
Oplossing: 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.
Dan moet je wel: "ON DELETE CASCADE" gebruiken toch?
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 ;)
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.
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.
ik dat het ook inactief word. in ieder geval bedankt voor jullie tijd!
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.
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.
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...
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...
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.
Robert_Deiman schreef op 15.01.2008 13:52:
Inderdaad, dát is niet zo'n ramp.Backups maak ik regelmatig, dus dat 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.
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.