[php] Backup table, ideeen en tips?

[Verwijderd]

ik wil een admin gaan maken voor mijn site... andere users kunnen dan ook de site aanpassen enzo nu wil ik uit veiligheid een backup table maken hoe gaat dat het beste ?

zou ik 1 backuptable kunnen maken voor alle andere tables of moet ik voor iedere table een aparte backuptable maken en moet ik die backup pas vullen als er iets gedelete wordt of is het beter om 2 keer weg te schrijven, 1 keer naar de backup en 1 keer naar de echte en dan uit de echte te deleten?

grtz Dreamzilla

[gorgi_19]

Waarom wil je een backuptable gaan maken? Je hebt normaal toch dagbackups

[Verwijderd]

wat is dat ?
soz

[drm]

Dat zou je bijvoorbeeld eventjes met de administrator van je webserver kunnen overleggen. Verder vraag ik me af of je niet MySQL i.p.v. PHP bedoelt

Mochten er door de admin van de server geen backups gemaakt worden, of vind je dat allemaal te lastig, zou je aan de slag kunnen met mysqldump icm. met cron (unix/linux) of een schedule (windows). In hoeverre je daar toegang toe hebt, moet je ook weer overleggen met de admin van de server, uiteraard

[Verwijderd]

drm schreef op 29 March 2003 @ 15:18:
Dat zou je bijvoorbeeld eventjes met de administrator van je webserver kunnen overleggen. Verder vraag ik me af of je niet MySQL i.p.v. PHP bedoelt

Mochten er door de admin van de server geen backups gemaakt worden, of vind je dat allemaal te lastig, zou je aan de slag kunnen met mysqldump icm. met cron (unix/linux) of een schedule (windows). In hoeverre je daar toegang toe hebt, moet je ook weer overleggen met de admin van de server, uiteraard

idd t gaat over mysql alleen ik gebruik die mysql in php je kunt mysql tog ook in andere atlen gebruiken ?

[Erkens]

wat je ook kan doen (en wat ik vaak doe bij dergelijke systemen) is geheel niets deleten, enkel de statuskolom updaten zodat het lijkt alsof deze gedelete is

[marty]

Erkens schreef op 29 March 2003 @ 21:05:
wat je ook kan doen (en wat ik vaak doe bij dergelijke systemen) is geheel niets deleten, enkel de statuskolom updaten zodat het lijkt alsof deze gedelete is

Ben ik het helemaal mee eens!

De ervaring heeft mij geleerd dat dat erg goed werkt. Er wordt namelijk nogal eens wat gedelete wat helemaal niet gedelete had mogen worden. En dan is het veel simpeler even een statusje te updaten dan een backup terug te zetten

[drm]

....met de ietwat flauw notie dat het hebt over een veld updaten en niet een kolom

[Erkens]

drm schreef op 30 March 2003 @ 01:24:
....met de ietwat flauw notie dat het hebt over een veld updaten en niet een kolom

was ff de benaming kwijt
maar het was wel duidelijk wat ik bedoelde

[Verwijderd]

hej dat is een goed idee ty
jullie bedoelen dus een nieuw veld met da naam delete oid en dan 0 en 1 en als 1 dan niet weergeven ?

[Erkens]

Verwijderd schreef op 30 maart 2003 @ 14:21:
hej dat is een goed idee ty
jullie bedoelen dus een nieuw veld met da naam delete oid en dan 0 en 1 en als 1 dan niet weergeven ?

zoiets, zelf zou ik een enum gebruiken met diverse mogelijkheden met statussen:

ALTER TABLE `tablename` ADD `status` ENUM('NORMAL','DELETED') DEFAULT 'NORMAL' NOT NULL

bijvoorbeeld
kan je later altijd nog statussen toevoegen zonder weer nieuwe kolommen te maken

[eborn]

Erkens schreef op 29 March 2003 @ 21:05:
wat je ook kan doen (en wat ik vaak doe bij dergelijke systemen) is geheel niets deleten, enkel de statuskolom updaten zodat het lijkt alsof deze gedelete is

Enige nadeel is dat bij grote tabellen alle oude 'zooi' er ook in blijft staan. Dan is het wel handig als je eens in de zoveel tijd alles naar een backup tabel verplaatst. Zal het zoeken en invoegen toch weer wat versnellen

[Erkens]

eborn schreef op 30 maart 2003 @ 16:45:
[...]
Enige nadeel is dat bij grote tabellen alle oude 'zooi' er ook in blijft staan. Dan is het wel handig als je eens in de zoveel tijd alles naar een backup tabel verplaatst. Zal het zoeken en invoegen toch weer wat versnellen

mja, dat kan, maar je kan ook aan indixen denken

[marty]

Erkens schreef op 30 March 2003 @ 16:47:
[...]

mja, dat kan, maar je kan ook aan indixen denken

Die maken het invoegen juist langzamer.... ik denk dat ie daar ook op doelde.
Maar dat weegt nog steeds niet op tegen de vele voordelen die het heeft het te laten staan vind ik. Tenzij je echt immense tabellen krijgt, maar dat is volgens mij niet het geval bij de TS

[Erkens]

marty schreef op 30 maart 2003 @ 16:50:
[...]
Die maken het invoegen juist langzamer.... ik denk dat ie daar ook op doelde.
Maar dat weegt nog steeds niet op tegen de vele voordelen die het heeft het te laten staan vind ik. Tenzij je echt immense tabellen krijgt, maar dat is volgens mij niet het geval bij de TS

idd, en mocht het op het laatst onwerkbaar traag worden bijvoorbeeld, kan je altijd nog een schoonmaak houden door alle records te deleten die die status hebben
dat is immers dan een "simpele" DELETE FROM table WHERE status='DELETED'

[drm]

Je zou dan imho beter een soort "prullenbak" principe kunnen hanteren. De mogelijkheid geven om de gebruiker iets op 'deleted' te zetten (in de prullenbak gooien), en de DELETE query uitvoeren (prullenbak legen), en natuurlijk dingen weer terug zetten uit de prullenbak (status weer terugzetten)

[Erkens]

drm schreef op 30 March 2003 @ 18:16:
Je zou dan imho beter een soort "prullenbak" principe kunnen hanteren. De mogelijkheid geven om de gebruiker iets op 'deleted' te zetten (in de prullenbak gooien), en de DELETE query uitvoeren (prullenbak legen), en natuurlijk dingen weer terug zetten uit de prullenbak (status weer terugzetten)

kan ook, ligt ermaar aan wat je precies wilt aanbieden aan je users, maar het principe blijft toch gewoon hetzelfde

[eborn]

marty schreef op 30 March 2003 @ 16:50:
[...]
Die maken het invoegen juist langzamer.... ik denk dat ie daar ook op doelde.
Maar dat weegt nog steeds niet op tegen de vele voordelen die het heeft het te laten staan vind ik. Tenzij je echt immense tabellen krijgt, maar dat is volgens mij niet het geval bij de TS

Daar doelde ik op ja In mijn situatie gaat het namelijk om een hoofd-tabel met 200.000+ records waar erg veel ingevoegd wordt. Vandaar mijn antwoord