Prullenbak tabel of gewoon erbij opslaan dat het verwijderd is?

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Jan terhuijzen

jan terhuijzen

14/08/2015 18:40:46
Quote Anchor link
Ik heb gemaakt dat als iemand een pagina of bericht verwijderd, dat het naar de prullenbak wordt verplaatst.
Ik werk er wel nog aan.

Een vraag die ik me nu stel is dat als je iets verwijderd dat dus zogenaamd naar de prullenbak wordt verplaatst, dan kan ik 2 dingen doen.
Ik kan bij de tabel van de gegevens een aparte kolom maken waar in staat of het is verwijderd of niet.
Zo kun je dan de gegevens negeren, en in de prullenbak alle gegevens ophalen die in de kolom hebben staan dat het 'verwijderd' is (en dus in de prullenbak zit).
Of ik maak een hele aparte tabel, en verplaats de rijen letterlijk, dus deleten van de rij in de gewone gegevens tabel, en een nieuwe rij met dezelfde gegevens maken in de tabel van verwijderde dingen.
 
PHP hulp

PHP hulp

16/11/2024 09:39:22
 
Lorenzo Sipkema

Lorenzo Sipkema

14/08/2015 18:50:11
Quote Anchor link
Doe wat je zelf het fijnste vind, ik zou het zelf opslaan in de zelfde tabel alleen er bij kolom maken dat het verwijderd is.
 
Willem vp

Willem vp

14/08/2015 18:58:19
Quote Anchor link
Ik zou gaan voor de extra kolom. Ten eerste scheelt dat in complexiteit (je hebt tenslotte alleen maar een update-query in plaats van een insert en delete). Ten tweede scheelt het in performance als je tabel erg groot wordt: een delete van een record kan dan vele malen langer duren dan een update.
 
- Ariën -
Beheerder

- Ariën -

14/08/2015 19:07:19
Quote Anchor link
Nog een reden om juist GEEN aparte tabel te gebruiken is dat je anders de Auto_Increment anders om zeep kan helpen als je iets terug wilt zetten.
 
Thomas van den Heuvel

Thomas van den Heuvel

14/08/2015 19:28:56
Quote Anchor link
Niet zozeer/alleen het auto_increment id is een probleem, je hebt mogelijk ook nog te maken met andere koppelingen die je bij de verplaatsing van tabel A naar tabel B moet verbreken, bij het terugplaatsen zul je deze dan weer moeten herstellen.

Je hebt dan dus (ook daardoor) een heleboel overhead. En de vraag is of het herstellen van deze relaties dan ook slaagt, want stel dat je in gerelateerde tabellen ook informatie hebt weggegooid?


Een (extra) argument voor het toevoegen van een een extra kolom boven de variant waarbij je met informatie heen en weer gaat slepen is dus dat je de onderliggende relaties onaangeroerd kunt laten als je een item "verwijdert". Er is daarmee ook min of meer gegarandeerd (als je alle relevante tabellen zo opzet) dat een hersteloperatie altijd slaagt.

Iets wat je niet uit het oog moet verliezen is de aard van de data en hoe je hier mee omgaat. Als dit soort situaties zelden voorkomen dan hoef je hier je hele ontwerp niet op af te stemmen voor-het-geval-dat. Indien dit soort herstelreparaties geregeld nodig zijn dan zou ik het mijzelf gemakkelijk maken (door zo'n extra kolom), maar ook eens kijken hoe je deze situaties kunt voorkomen.
 
Johan K

Johan K

15/08/2015 19:15:03
Quote Anchor link
Het makkelijkste is een extra kolom erin zetten met een integer als type. Je zou deze integer kunnen gebruiken als:

1: Bericht ongelezen.
2: Bericht gelezen.
4: Bericht naar prullenbak.
8: Bericht verwijderd. (bericht niet meer laten zien aan gebruiker)

Waarom deze waardes? Met php kan je "bitwise operators" gebruiken om te kijken of 1 bit is gezet. Hetzelfde als error reporting waarbij je constants erbij kan zetten om deze ook te laten weergeven.

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
<?php
  if($data & MAIL::UNREAD){
   // add class to li or table to make it stand out..
  }
?>


Maar doe vooral wat jouw het makkelijkste is.
Gewijzigd op 15/08/2015 19:41:11 door Johan K
 



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.