[ALG] Database structuur forum

[NMe]

Ik realiseer me dat topics die op deze lijken in het verleden al vaak gemaakt zijn, en ik verwacht dan ook dat deze topic in no time gesloten zal worden, maar ik probeer het alsnog, omdat mijn topic toch iets algemener is, en omdat er volgens mij wel een zinnige discussie uit kan komen.

Ik heb een structuur opgezet voor de database die ik wil gaan gebruiken voor een forum. Ik wil deze databasestructuur op stage gaan gebruiken in ASP, en voor mezelf in PHP. Ik heb alles netjes genormaliseerd, en denk een nette structuur bij elkaar te hebben.

Ik heb mijn structuur hier online gezet, voor mensen die interesse hebben. Gebruik het gerust voor je eigen forum als je wil. Er mist alleen een tabel usergroup, maar die zou alleen een group id, een group naam en wat velden over rechten moeten bevatten.

Ik wil graag weten of jullie vinden dat ik gekke dingen doe, of dat ik het beter op een andere manier had kunnen aanpakken. Alle kritiek is welkom (complimenten ook maar die verwacht ik niet ).

[RobIII]

Postcount is overbodig (die kun je met een count op je posts tabel uitlezen) en ik zou per user een paar bitjes reserveren voor wat user-rechten (HK-access )

Verder gebruik je "kind" in je topics tabel. Daar zou ik een fk van maken en een tabel met topic-types maken.

[ Voor 27% gewijzigd door RobIII op 08-03-2004 12:55 ]

[gorgi_19]

Een user is geen moderator; een user zit in een of meerdere groepen. Deze groepen hebben 1 of meerdere rechten op een of meerdere forums. Ik denk dat je je nu vrij veel beperkt.

RobIII schreef op 08 maart 2004 @ 12:53:
Postcount is overbodig (die kun je met een count op je posts tabel uitlezen))

Die lijkt me erg zwaar, wil je die gebruiken. Per forum het aantal posts bijhouden en per user de postcount lijkt me geen slechte gedachte.

[ Voor 48% gewijzigd door gorgi_19 op 08-03-2004 12:54 ]

[RobIII]

gorgi_19 schreef op 08 maart 2004 @ 12:53:
[...]

Die lijkt me erg zwaar, wil je die gebruiken. Per forum het aantal posts bijhouden en per user de postcount lijkt me geen slechte gedachte.

Is ook wel weer zo... Hangt een beetje van aantal Posts af he?

[ Voor 23% gewijzigd door RobIII op 08-03-2004 12:56 ]

[NMe]

gorgi_19 schreef op 08 maart 2004 @ 12:53:
Een user is geen moderator; een user zit in een of meerdere groepen. Deze groepen hebben 1 of meerdere rechten op een of meerdere forums. Ik denk dat je je nu vrij veel beperkt.

Ik weet niet of dit nou echt zo'n beperking is? Als je 4 moderators hebt met elk verschillende rechten, dan moet je daar 4 verschillende user groups voor maken. Lijkt me nogal een overkill. Nu hoef ik alleen maar een entry per forum in die moderators tabel, afgescheiden van usergroups.

gorgi_19 schreef op 08 maart 2004 @ 12:53:
Die lijkt me erg zwaar, wil je die gebruiken. Per forum het aantal posts bijhouden en per user de postcount lijkt me geen slechte gedachte.

Dat is inderdaad de reden dat ik hiervoor gekozen heb.

RobIII schreef op 08 maart 2004 @ 12:53:
...en ik zou per user een paar bitjes reserveren voor wat user-rechten (HK-access )

Daar wou ik liever een aparte tabel voor maken, zoals ook al een beetje verkapt staat in mijn startpost. Normaliseren.

[ Voor 16% gewijzigd door NMe op 08-03-2004 12:59 ]

[gorgi_19]

RobIII schreef op 08 maart 2004 @ 12:55:
[...]

Is ook wel weer zo... Hangt een beetje van aantal Posts af he?

Als je verwacht dat 2 users gemiddeld een jaar lang 1 post per dag maken, kan je het overwegen.. Anders lijkt me het bijhouden in een kolom geen slechte optie..

[gorgi_19]

NMe84 schreef op 08 maart 2004 @ 12:57:
Ik weet niet of dit nou echt zo'n beperking is? Als je 4 moderators hebt met elk verschillende rechten, dan moet je daar 4 verschillende user groups voor maken. Lijkt me nogal een overkill. Nu hoef ik alleen maar een entry per forum in die moderators tabel, afgescheiden van usergroups.

Als je 4 moderators hebben, met allemaal dezelfde rechten, hoef je maar 1 groep te maken. Jij kan niet eens verschillende rechten voor de moderators maken.

[NMe]

gorgi_19 schreef op 08 maart 2004 @ 12:58:
Als je 4 moderators hebben, met allemaal dezelfde rechten, hoef je maar 1 groep te maken. Jij kan niet eens verschillende rechten voor de moderators maken.

Hangt ervanaf wat je onder rechten verstaat. Ik maak straks een usergroup moderator, die aangeeft welke rechten je hebt (lezen, wijzigen, verwijderen, enz.). In combinatie met mijn tabel moderator kun je zien op welke fora je die rechten precies hebt. Op alle andere fora ben je gewoon een normale gebruiker. Vandaar dit systeem.

[djluc]

Heeft een post wel een title nodig?

[NMe]

djluc schreef op 08 maart 2004 @ 13:29:
Heeft een post wel een title nodig?

Daar heb ik zelf ook een tijdje over nagedacht, en het is inderdaad een minder belangrijk veld. Je ziet wel vaak op fora zo'n veld voor een title dat standaard is gevuld met "Re: Topictitel". Ik heb besloten dit ook maar te doen, omdat de implementatie die ik ga doe in ASP een titel vereist voor een post in de manier van weergeven die mijn opdrachtgever vraagt.

[Flard]

offtopic:
Misschien een beetje een off-topic vraag: maar waarmee heb je dat schema gemaakt?
Ik neem dat je daar een programma voor hebt?

Verder nog wat kleine tips:
Misschien is het handig om een user ook een title te geven ("Forum Administrator", "Webmaster", e.d.)

Soms kan het ook handig zijn om een forum bepaalde rechten te geven, mocht je het niet te moeilijk willen doen, dan kun je bijvoorbeeld forum een extra veld MinViewLevel, MinNewTopicLevel, MinPostLevel, met in al deze velden in Enumerator ('Iedereen', 'Registered', 'Moderator', 'Admin'). Op die manier kun je dan ook een nieuws forum maken waar alleen moderators kunnen posten.

[NMe]

Flard schreef op 08 maart 2004 @ 23:01:

offtopic:
Misschien een beetje een off-topic vraag: maar waarmee heb je dat schema gemaakt?
Ik neem dat je daar een programma voor hebt?

Dit is gewoon een screenshot van de weergave van relaties tussen tabellen in Access 2000. Bij het scherm van een query maken rechts op de titelbalk klikken en dan relaties. Daarna met Photoshop HTML gegenereerd en wat Javascript erbij gepleurd.

Flard schreef op 08 maart 2004 @ 23:01:
Verder nog wat kleine tips:
Misschien is het handig om een user ook een title te geven ("Forum Administrator", "Webmaster", e.d.)

Soms kan het ook handig zijn om een forum bepaalde rechten te geven, mocht je het niet te moeilijk willen doen, dan kun je bijvoorbeeld forum een extra veld MinViewLevel, MinNewTopicLevel, MinPostLevel, met in al deze velden in Enumerator ('Iedereen', 'Registered', 'Moderator', 'Admin'). Op die manier kun je dan ook een nieuws forum maken waar alleen moderators kunnen posten.

Hmm, dat laatste had ik nog niet bedacht, goeie tip. Ik zal het alleen iets anders implementeren denk ik.

[mocean]

Los van de structuur zou ik wat aan je veld-namen veranderen. zo is 'starter' een ID, maar dat zie je niet aan de veldnaam.

Ik doe zelf altijd het volgende: de eerste letter van een veldnaam geeft het datatype (min of meer) aan:
n = number
t = text
d =date
Eerste letter daarna is een hoofdletter.


Verder is het handig gewoon alle autonumers van een tabel ID te noemen, dus met het gegeven hierboven nId.

Verwijzingen van een tabel naar een andere doe ik altijd a;s [tabelnaam]_[veldnaam]. 'starter' uit de tabel topic zou dan worden: user_nId

als je je hier aan houdt ga je veel minder fouten in je SQL maken.

[ Voor 3% gewijzigd door mocean op 08-03-2004 23:59 ]

[NMe]

mocean schreef op 08 maart 2004 @ 23:59:
[...]
als je je hier aan houdt ga je veel minder fouten in je SQL maken.

Ik maak sowieso nooit veel fouten in SQL omdat ik de database structuur wel ken, maar ik denk dat ik het mezelf toch maar ga aanleren om wat duidelijker te zijn. Niet voor mezelf, maar voor projecten waar ik aan werk. TNX!

[Bosmonster]

Velden [tabelnaam]_[veldnaam] noemen vind ik persoonlij juist een hele vervelende methode. Je hebt namelijk al je tabelnaam.veldnaam constructie en dat wordt dan tabelnaam.tabelnaam_veldnaam. Daar worden je queries onnodig lang en onoverzichtelijk van. JOIN kun je veel eenvoudiger afvangen met Aliassen.

[drm]

- Voor wat betreft de fora en de categorien zou ik nog een position veld opnemen.

- Het is imo een goede gewoonte in tabellen die door admins e.d. bij te houden zijn ook een date_modified en date_created veld op te nemen voor "administratieve" doeleinden, zeg maar.

- Ik zou locked ook in de kind ENUM opnemen en het veld state noemen. Gesloten stickies en announcements hebben tenslotte niet zoveel zin, of wel?

- Als je het password veld codeert in de database, zou ik die codering in de veldnaam opnemen, bijvoorbeeld md5_password of sha1_password

- Ik mis nog een sessietabel (handig voor uitloggen van andere users door admins e.d.)

- Voor wat betreft de posts zou ik ook 2 datumvelden opnemen: date_created / date_modified

- Wellicht heeft het zin om posts ook 'lock-baar' te maken. Hangt een beetje van de wensen af.

- Koppeltabel Moderator zou ik er ook uitgooien en een echte rechtenstructuur maken. Die tabel voegt namelijk bar weinig toe als je ook nog eens groepen gaat maken.

- Misschien nog iets van een notitiesysteem per user? We houden hier op GoT van elke user zgn. notes bij, kan behoorlijk handig zijn

- topic- en postcount zou ik, als je inderdaad verwacht dat het zinvol is voor de performance, dan ook meteen in de fora, categorien en (evt) topics bijhouden. Die laatste is ws. wel een beetje overkill als je je indices goed zet, maar goed.

Over het algemeen gesproken zou ik de namen van de velden veel duidelijker maken. Zoals hierboven al genoemd is starter niet echt intuitief, maar ook zaken als fid, cid, time_stamp, website, etc. zijn imo niet echt om over naar huis te schrijven Kortom: verbose is fijn

[ludo]

Ik zou de tabellen category en forum samenvoegen. Op deze manier beschouw je een category eigenlijk ook als forum, waar je dan geen topics in kan plaatsen. Op deze manier kan je ook eenvoudig subfora e.d. maken.

[NMe]

drm, de meeste dingen die je zei volg ik wel en zijn ook goeie ideeën, maar ik heb nog wel wat vraagjes en opmerkingen over andere dingen.

drm schreef op 09 maart 2004 @ 10:20:
- Ik zou locked ook in de kind ENUM opnemen en het veld state noemen. Gesloten stickies en announcements hebben tenslotte niet zoveel zin, of wel?

In het geval van een open of gesloten announcement heb je gelijk, die kan in principe beter maar 1 lock state hebben. Maar een sticky moet iets zijn waar je óf wel, óf niet op kan reageren... Vandaar mijn keuze.

drm schreef op 09 maart 2004 @ 10:20:
- Ik mis nog een sessietabel (handig voor uitloggen van andere users door admins e.d.)

Hoe implementeer ik zoiets? Gewoon bij het inloggen op de pagina het sessie id in de database zetten, en eruit halen bij het uitloggen? En als het sessie id niet meer in de database staat, dan automatisch uitloggen?

drm schreef op 09 maart 2004 @ 10:20:
- Wellicht heeft het zin om posts ook 'lock-baar' te maken. Hangt een beetje van de wensen af.

Topics zijn toch al lockbaar? Hoe stel je je een gelockte post dan voor?

drm schreef op 09 maart 2004 @ 10:20:
- Koppeltabel Moderator zou ik er ook uitgooien en een echte rechtenstructuur maken. Die tabel voegt namelijk bar weinig toe als je ook nog eens groepen gaat maken.

Dit is nou al door meerdere mensen gesuggereerd, maar ik zie niet hoe ik met een groepen/rechtenstructuur individuele rechten per mod per forum kan instellen zonder een hele meuk aan redundantie. Misschien dat iemand een voorbeeld kan geven?

ludo schreef op 09 maart 2004 @ 11:03:
Ik zou de tabellen category en forum samenvoegen. Op deze manier beschouw je een category eigenlijk ook als forum, waar je dan geen topics in kan plaatsen. Op deze manier kan je ook eenvoudig subfora e.d. maken.

In mijn geval weet ik zeker dat de structuur niet dieper gaat dan dit, lijkt me ook nogal zinloos. Daarom is een database met 2 tabellen volgens mij overzichtelijker dan een met maar 1 tabel voor categorieën en fora.

[Marijn_S]

NMe84 schreef op 09 maart 2004 @ 12:52:
[...]

Topics zijn toch al lockbaar? Hoe stel je je een gelockte post dan voor?

[...]

Als een moderator iemands post edit, zou je die post kunnen locken zodat de poster niet het weer terug verandert of reageert op de edit van de moderator.

[ripexx]

NMe84 schreef op 09 maart 2004 @ 12:52:

In het geval van een open of gesloten announcement heb je gelijk, die kan in principe beter maar 1 lock state hebben. Maar een sticky moet iets zijn waar je óf wel, óf niet op kan reageren... Vandaar mijn keuze.

Dit alles ligt er maar aan wat je daadwerkelijk wilt bereiken. Wil je eenvoudig topic statussen kunnen uitbreiden? Meestal ben je met drie of vier statussen klaar het is dan ook maar net waar je zelf d evoorkeur aangeeft.

Hoe implementeer ik zoiets? Gewoon bij het inloggen op de pagina het sessie id in de database zetten, en eruit halen bij het uitloggen? En als het sessie id niet meer in de database staat, dan automatisch uitloggen?

Gewoon een eigens sessie manager schrijven, zou moeilijk is dat niet en er zijn zat voorbeelden voor te vinden. Voordeel is zoals drm zegt dat je heel eenvoudig iemand kan uitloggen.

Topics zijn toch al lockbaar? Hoe stel je je een gelockte post dan voor?

Hier zijn verschillende manieren voor te bedenken, door aan je message tabel een extra veld toe te voegen die aangeeft of een bericht gelocked is, maar je kan het ook doen door je edit gegevens op te slaan dus bijvoorbeeld edit_uid en edit_timestamp) Afhankelijk van je rechten in een bepaald fora mag je dit overrulen etc.

Dit is nou al door meerdere mensen gesuggereerd, maar ik zie niet hoe ik met een groepen/rechtenstructuur individuele rechten per mod per forum kan instellen zonder een hele meuk aan redundantie. Misschien dat iemand een voorbeeld kan geven?

Er zijn zat voorbeelden van te vinden van heel eenvoudige role based right systemen tot zeer uitgebreide zoals dat van react ([rml][ php/[ my]sql] inherited rechtensysteem[/rml])

In mijn geval weet ik zeker dat de structuur niet dieper gaat dan dit, lijkt me ook nogal zinloos. Daarom is een database met 2 tabellen volgens mij overzichtelijker dan een met maar 1 tabel voor categorieën en fora.

Dit ligt natuurlijk helemaal aan je wensen maar wil j een flexibelere opzet dan zou je er aan kunnen denken.

[drm]

NMe84:
In het geval van een open of gesloten announcement heb je gelijk, die kan in principe beter maar 1 lock state hebben. Maar een sticky moet iets zijn waar je óf wel, óf niet op kan reageren... Vandaar mijn keuze.

fair enough

Hoe implementeer ik zoiets? Gewoon bij het inloggen op de pagina het sessie id in de database zetten, en eruit halen bij het uitloggen? En als het sessie id niet meer in de database staat, dan automatisch uitloggen?

Heel eenvoudig: als het sessie-id (of een of andere hash/user_id combinatie in de cookie) in de sessietabel voorkomt ben je ingelogd, anders niet. Uitloggen betekent dus gewoon de betreffende record uit de sessietabel halen en (evt.) login-cookie of session id trashen.

Topics zijn toch al lockbaar? Hoe stel je je een gelockte post dan voor?

Ik kan me voorstellen dat je wilt voorkomen dat mensen alsnog posts editten, bijvoorbeeld. Of dat je deleted posts niet uit je database wilt verwijderen maar gewoon onzichtbaar wilt maken.

Dit is nou al door meerdere mensen gesuggereerd, maar ik zie niet hoe ik met een groepen/rechtenstructuur individuele rechten per mod per forum kan instellen zonder een hele meuk aan redundantie. Misschien dat iemand een voorbeeld kan geven?

Er is een heel aantal verschillende indelingen voor te bedenken. De vraag is waar je precies de koppeling met het forum plaats wilt vinden, en ik denk dat de beste manier om dat te doen is in de definitie van de groep zelf.

Voorbeeld:


tabel rights

right_id	action
1	delete_post
2	edit_post
3	change_topic_state
4	lock_topic

table group

group_id	forum_id	name
1	1	Moderator forum X

table group_right

group_id	right_id
1	1
1	2
1	3
1	4

Als je dan een user aan de group 1 koppelt, zie je direct dat die user in forum met id 1 posts kan deleten, posts kan editen, stickies kan zetten, topics kan locken...

Als je dit verder doordrijft kun je zelfs de niet ingelogde user, de gebande user, de ingelogde user allemaal in groepen plaatsen. Het enige werk zit hem dan in de groepen indelen, maar dan heb je wel het meest flexibele rechtensysteem; je kunt bij een request gewoon kijken of de gebruiker wel 'gekoppeld' is aan een bepaalde actie en zo nee, laat een bericht zien over het niet mogen uitvoeren van die actie. Zo ja, handel af.

offtopic:
Overigens zou je er voor kunnen kiezen de koppeling tussen rechten en fora ook forumbreed en/of per categorie te doen. Dat is imho ook het meest discutabele punt aan zo'n systeem; waar je precies de koppelingen legt. Elke manier heeft wel z'n eigen voor- en nadelen.

[NMe]

Tnx, daar kan ik wat mee. Ik ga meteen aan de slag.

drm schreef op 09 maart 2004 @ 14:32:

offtopic:
Overigens zou je er voor kunnen kiezen de koppeling tussen rechten en fora ook forumbreed en/of per categorie te doen. Dat is imho ook het meest discutabele punt aan zo'n systeem; waar je precies de koppelingen legt. Elke manier heeft wel z'n eigen voor- en nadelen.

Misschien een extra enum veld scope in de group tabel met daarin (uiteraard) de scope waar het geldig is? Lijkt mij het makkelijkst te implementeren terwijl het flexibel blijft.

[Verwijderd]

hehe, toevallig, ik zit met het zelfde probleem, de tabel structuur van drm gebruik ik nu zo half, maar wat als een users meerdere forums mag modereren?

_{sorry voor de kick, maar een nieuw topic is ook overbodig}

[faabman]

gebruikers zijn lid van groepen en een groepen hebben bepaalde rechten op bepaalde fora

[ Voor 10% gewijzigd door faabman op 16-03-2004 16:43 . Reden: ff ]

[curry684]

Verwijderd schreef op 16 maart 2004 @ 16:37:
hehe, toevallig, ik zit met het zelfde probleem, de tabel structuur van drm gebruik ik nu zo half, maar wat als een users meerdere forums mag modereren?

_{sorry voor de kick, maar een nieuw topic is ook overbodig}

Wie houdt je tegen middels een koppeltabel een many-to-many relatie tussen users en groups te leggen?

[Verwijderd]

me moeder

_{nee niet aangedacht ja, thx}

[.oisyn]

NMe84 schreef op 08 maart 2004 @ 12:50:
Ik realiseer me dat topics die op deze lijken in het verleden al vaak gemaakt zijn, en ik verwacht dan ook dat deze topic in no time gesloten zal worden, maar ik probeer het alsnog, omdat mijn topic toch iets algemener is, en omdat er volgens mij wel een zinnige discussie uit kan komen.

zou je voortaan eerst een mod willen mailen ipv op goed geluk een topic openen? Je zegt zelf al dat je er niet zeker over was, dan is een mailtje toch weinig moeite? (bovendien geven wij mensen die de moeite nemen eerst een mailtje te sturen sowieso vaak al wat meer slack, juist omdat ze die moeite gedaan hebben)

[.oisyn]

drm schreef op 09 maart 2004 @ 10:20:
- Ik zou locked ook in de kind ENUM opnemen en het veld state noemen. Gesloten stickies en announcements hebben tenslotte niet zoveel zin, of wel?

Imho is status een groepje flags, niet een bepaalde waarde. Geeft ook een stuk meer mogelijkheden. Op mijn eigen forum heb ik vlaggetjes voor gesloten, sticky en announcement. Je kunt dus ook in niet-gesloten stickies of announcements reageren (zouden ze in react ook eens moeten introduceren, dan kun je bepaalde discussies hoog houden. Denk bijvoorbeeld aan het P&W voorsteldraadje)

- topic- en postcount zou ik, als je inderdaad verwacht dat het zinvol is voor de performance, dan ook meteen in de fora, categorien en (evt) topics bijhouden. Die laatste is ws. wel een beetje overkill als je je indices goed zet, maar goed.

mwoa, misschien overkill, maar het versimpeld wel veel van je db queries, zoals bijvoorbeeld het moven van alle topics naar een ander forum (SUM(postcount) ipv een join van de posts op de topics mbt een bepaald forum)


klik hier voor mijn eigen forum db layout

categories
category_id
name
priority
moderators (tekst)

forums
forum_id
category_id
name
priority
daysvisible
description
moderators (tekst)
numtopics
numposts
lastpost_time
lastpost_user_id

topics
topic_id
forum_id
user_id
title
status
note
start_time
numposts
lastpost_time
lastpost_user_id

posts
post_id
topic_id
user_id
post
post_html
post_time
post_ip
edit_time
edit_user_id
edit_ip
locked

users
user_id
group_id
name
password
activationcode
status
email
regemail
regtime
currentvisit
lastvisit
numtopics
numposts
numnotes
prefs
...

notes
note_id
for_user_id
user_id
note
note_html
post_time
edit_time
edit_user_id

sessions
session_id
user_id
data
time
hits
ip

groups
group_id
level
name
description
status

rights
group_id
subject (enum 'global', 'category', 'forum')
subject_id
tokens_allow
tokens_deny

Bij mij kan een user maar in 1 group zitten, heb ik expres voor gekozen omdat het anders overkill zou zijn voor waar het draait (3 mods, iedereen kan overal modden). Dit is wel iets dat ik in de toekomst aan wil passen

Die tokens zijn ook gewoon een textuele lijsten van integers omdat ik het onzin vond om dat helemaal met een koppeltabel te regelen (en dus de tokens apart in de db op te slaan)

[ Voor 7% gewijzigd door .oisyn op 16-03-2004 17:45 ]