[DISC] Wat doe je met een gedeletete user?

Met de grote DB crash een tijdje terug hier is er voor gekozen om 1 ID aan te nemen voor users die het niet gehaald hebben (waarvan de login verloren is gegaan) ..

Het gebeurd ook nog wel eens dat een user eist dat al zijn postings worden verwijderd als de user wordt gedelete (is dit hard te maken eigenlijk?) ..

Als ik een CMS zou maken , zou ik dus 2 opties er in zetten :

1 : Deleted users naar een dummy account zetten zodat de posts niet gek gaan doen.
2 : Na het deleten ook de posts deleten.

D.m.v. een query zou je nog alle links die linken naar de "gedelete" user kunnen updaten naar iets zinvols..

Mja de oplossing die je nu hebt lijkt me het beste. Account gewoon op inactief zetten maar alle content laten staan. De users is het er niet mee eens? stuur ze even richting je Algemene Voorwaarden of iets dergelijks.

Als je ook de content automatisch verwijdert (foreign key) wanneer je de user verwijdert, verziek je inderdaad je hele forum/website. No-go imho

Reveller schreef op vrijdag 04 augustus 2006 @ 14:09:
Stel dat GoT de posts van een bepaalde user zou verwijderen, dan slaan bepaalde draadjes geheid nergens meer op.

Reden genoeg voor ons om in onze Algemene Voorwaarden op te nemen dat we géén accounts verwijderen. Users verwijderen zou ik in elk geval nooit (meer) fysiek doen. Ik heb dat één keer mogelijk gemaakt bij een website, en daar heb ik nu nog steeds last van.

Users verwijderen creeert 2 problemen:

- referentiele integriteit met content die de user geplaatst heeft. dat een user om wat voor reden dan ook de toegang ontnomen wordt, wil niet meteen zeggen dat al zijn content weg moet.
- terughalen van gegevens mbt. deze user. Fysiek verwijderen betekent dat je alle data omtrent deze user kwijt bent (tenzij je moeilijk gaat doen met een soort prullenbak).

Dus gewoon de account deactiveren en eventuele ongewenste content editen/op inactief zetten.

In mijn applicaties die iets met databases te maken hebben delete ik nooit wat. Ik neem meestal een boolean op die aangeeft of het record gedelete is. Deze komt dan in overzichten niet meer terug.

Janoz schreef op vrijdag 04 augustus 2006 @ 14:51:
In mijn applicaties die iets met databases te maken hebben delete ik nooit wat. Ik neem meestal een boolean op die aangeeft of het record gedelete is. Deze komt dan in overzichten niet meer terug.

Levert dat geen (preformance) problemen op? Ik kan me voorstellen dat sommige tabellen dan onwijs groot worden.

Speedener schreef op vrijdag 04 augustus 2006 @ 15:01:
[...]

Levert dat geen (preformance) problemen op? Ik kan me voorstellen dat sommige tabellen dan onwijs groot worden.

Wat vind je onwijs groot?

gorgi_19 schreef op vrijdag 04 augustus 2006 @ 15:05:
[...]

Wat vind je onwijs groot?

Sessie tabel van een middelgrote website . Maar ik merk het regelmatig ook al bij gastenboeken die 5000+ posts hebben, dat de laad tijd soms flink op kan lopen.

Speedener schreef op vrijdag 04 augustus 2006 @ 15:01:
[...]

Levert dat geen (preformance) problemen op? Ik kan me voorstellen dat sommige tabellen dan onwijs groot worden.

Als het aantal records in je database inverse invloed heeft op je performance, doe je iets fout.
(Tenzij je natuurlijk continu de hele tabel wilt ophalen.)

[ Voor 8% gewijzigd door Not Pingu op 04-08-2006 15:09 ]

Sessies ruim je sowieso regelmatig op, die hoef je echt niet te bewaren. En 5000 records is natuurlijk niks voor een database. Als dat traag is dan is de opbouw van de database slecht (indexes verkeerd e.d.), of het schilletje eromheen is traag (geschreven).

Speedener schreef op vrijdag 04 augustus 2006 @ 15:07:
[...]

Sessie tabel van een middelgrote website . Maar ik merk het regelmatig ook al bij gastenboeken die 5000+ posts hebben, dat de laad tijd soms flink op kan lopen.

5000+ rijen in een DB is niks. Die paar extra records die je hebt in een tabel van eventueel verwijderde users zijn echt te verwaarlozen.

Auteursrecht is wat anders dan eigendomsrechten. Als je een boek koopt, dan is dat boek van jou, maar de schrijver heeft het auteursrecht.

Het lijkt me dat je een voorwaarde opneemt die stelt dat de website een onherroepelijk, niet-exclusief recht heeft geplaatste reacties in hun oorspronkelijke context weer te geven. Daarmee dragen gebruikers niet hun auteursrecht over, maar het betekent wel dat bijdragen niet verwijderd hoeven te worden, als de gebruiker geblokkeerd wordt.

Ik weet niet precies wat Tweakers.net daarover in de voorwaarden heeft staan, maar ik ga er in ieder geval vanuit dat dingen die ik hier post nooit meer kan verwijderen (en zorg dus ook dat ik geen dingen post die ik niet gepubliceerd wil hebben).

-NMe- schreef op vrijdag 04 augustus 2006 @ 15:18:
Auteursrecht is wat anders dan eigendomsrechten. Als je een boek koopt, dan is dat boek van jou, maar de schrijver heeft het auteursrecht.

Dat klopt, maar het recht tot openbaarmaking is essentieel onderdeel van het auteursrecht. In principe ga je bij het posten akkoord met openbaarmaking (je geeft T.net het recht om dat te doen). Het punt waar het dan om draait is of je dat terug kunt draaien. Ik denk dat de passage uit de AV voldoende is om te zorgen dat hier geen discussie om kan intstaan (en dus posts on-line mogen blijven), maar goed je weet nooit.
Het behoud van auteursrecht voor posters lijkt me verder vrij essentieel. Anders zou elk stukje code dat je hier post in eens "van T.net zijn". Dan post geen mens nog bruikbare code, a) omdat je het dan kwijt bent en b) omdat iedereen die het gebruikt het risico loopt om door tweakers gedaagd te worden wegen copyrightschending

Wat betreft posts op een forum is het heel simpel. Gewoon in je gebruiksvoorwaarden opnemen dat de auteur dient in te stemmen met het altijd durende recht tot publicatie op het forum van de geleverde postings.

Een bijzonder punt is echter moderatie op een forum. In principe worden dan zaken gewijzigd waar de auteur het niet mee eens kan zijn.

Reveller schreef op vrijdag 04 augustus 2006 @ 16:31:
[...]

Ja, maar het lijkt me dat je dat kunt ondervangen door iets als "<website> heeft het recht reakties te wijzigen wanneer de inhoud hiervan niet in overeenstemming is met de gebruikersvoorwaarden" of zoiets

9. Tweakers.net BV houdt zich uitdrukkelijk het recht voor om de vormgeving en/of inhoud van berichten, reacties of welke andere vorm van content ook, te wijzigen of te verwijderen.

In de applicaties die ik heb gebouwd doe ik over het algemeen twee dingen bij ex-users:
- Boolean bij de user omzetten zodat user niet meer getoond wordt in de querys
- Alle rechten van een gebruiker verwijderen

Just my 2 cents...

De meeste voorwaarden nemen inderdaad op dat wijzigingen mogelijk zijn door moderetters. Om beter te zijn zouden Moderetters eigenlijk enkel maar de post mogen verbergen met een klein notaatje zoals op GoT gebeurt. Als iemand de post veranderd om het beter te maken kom je inderdaad met andere legale problemen.

Wat ik doe is gewoon de user disablen (1/0) in een database. In een goed opgezette database staan de users in een aparte tabel dan de posts en comments. Een fout die ik ook soms zie is dat je een SQL achteraf in je code filtert. Imho moet een SQL query het kleinste mogelijk aantal records verkrijgen die je rechtstreeks in je code kunt flikkeren. Ik heb inderdaad mensen gezien die de rechten vaststellen in code (if($rights=="poster") { echo $username terwijl ze evengoed een WHERE rights="poster" hadden kunnen doen en dan die if functie eruit kunnen halen en opeens 400 records minder moeten verwerken.

Als toevoeging kan ik nog even zeggen dat de populaire messageboard software phpBB een concept gebruikt met een user tabel én een username veldje in de phpbb_posts tabel. Dit username veldje is standaard leeg en er wordt naar een user_id gelinkt, maar als iemand zichzelf uitschrijft als gebruiker gaat het systeem eerst de naam van de uitgeschreven gebruiker in alle posts zetten van die gebruiker en gooit daarna het username record weg in de phpb_users tabel.

Dit is een andere benadering dan de meesten hierboven aandragen. Het ligt helemaal aan de situatie hoe je het wil aanpakken. phpBB heeft geen referentiele integriteit, er zijn nergens constraints in het datamodel. Ik ben daar op zich wel voorstander van, omdat het je helpt de data consistent te houden op database niveau. Een programmeerfoutje op je 2e tier hoeft dan geen drastische gevolgen te hebben.

DexterDee schreef op vrijdag 04 augustus 2006 @ 23:26:
x heeft geen referentiele integriteit, er zijn nergens constraints in het datamodel. Ik ben daar op zich wel voorstander van, omdat het je helpt de data consistent te houden op database niveau.

DexterDee schreef op vrijdag 04 augustus 2006 @ 23:26:
Een programmeerfoutje op je 2e tier hoeft dan geen drastische gevolgen te hebben.

Integendeel, een programmeerfout kan volgens mij juist wel drastische gevolgen hebben.
Het doel van constraints is om de integriteit van de database te waarborgen.

[ Voor 13% gewijzigd door Verwijderd op 05-08-2006 21:30 ]

Verwijderd schreef op zaterdag 05 augustus 2006 @ 18:16:
Integendeel, een programmeerfout kan volgens mij juist wel drastische gevolgen hebben.
Het doel van constraints is om de integriteit van de database te waarborgen.

Je hebt me verkeerd begrepen. Ik zei dat het geen grote gevolgen hoeft te hebben, niet dat het niet alsnog kan. Constraints kunnen je gewoon in sommige gevallen helpen om minder schade toe te brengen aan de data door een programmeerfout. Als je bijvoorbeeld een where clause in je SQL vergeet waardoor alle gebruikers worden weggegooid, terwijl je er er maar 1 wilde weggooien, dan kan het handig zijn dat je een constraint hebt gelegd naar een tabel met geschreven artikelen, waardoor er een stuk minder gebruikersrecords naar de prullenbak gaan. Of nog beter, als je een record insert met een missende foreign key relatie, dan resulteert de query in een error en niet in een nieuw record die niet meer referentieel integer is.

Natuurlijk zijn er nog tig voorbeelden te bedenken van programmeerfouten waarbij dit absoluut niet opgaat. Maar dat was mijn punt niet, ik wilde alleen duidelijk maken dat je in sommige gevallen door constraints de schade van programmeerfouten kunt beperken.

De reden dat ik phpBB aanhaalde is dat daar allerlei synchronisatiescriptjes in zitten die de referentiele integriteit 'scriptmatig' moeten herstellen van data waartussen geen constraints bestaan. Als administrator van een groot bulletinboard gebaseerd op phpBB kan ik uit eigen hand vertellen hoe vervelend data inconsistency binnen je database is.