[FORUM] opslaan pref's; aparte tabel?

Alleen een aparte tabel creeren als je ook van plan bent om in die tabel meerdere records per user op te nemen. (dus 1:n)
Als je dat niet van plan bent, kan je beter de tabel uitbreiden en eventueel een view maken op die tabel met de usergegevens

Cookie kan ook nog.


Maar idd, geen aparte tabel. Da's niet 'normaal'.

Aparte tabellen komt de overzichtelijkheid iig wel ten goede.

Een juiste ontwerpbeslissing leidt tot overzicht.
Een willekeurige keuze (dus niet gebasseerd op een ontwerprichtlijn) leidt allwen tot verwarring

diverse fora kennen enkel aan/uit 'toggles'

bij mysql is het gebruik van een set() of enum() veld (pick you choice, rtfm dan wel handig (weinig ruimte, makkelijk te lezen)...

Op maandag 10 december 2001 21:20 schreef chem het volgende:
diverse fora kennen enkel aan/uit 'toggles'

bij mysql is het gebruik van een set() of enum() veld (pick you choice, rtfm dan wel handig (weinig ruimte, makkelijk te lezen)...

Snap ik dit? Ergens anders bedoeld??

Op maandag 10 december 2001 21:18 schreef trebel het volgende:
please define 'juiste ontwerpbeslissing'?



nee geintje,
bedoel, dit is iets wat je eenmalig tegenkomt in forum, dus richtlijn?

Heel kort dan:
Een tabel over users met de pref's er als kolommen in is heel snel, maar als je een nieuwe pref wilt bijhouden, krijg je een tabelwijziging.

Als je de prefs in een aparte tabel bijhoudt met als kolommen: user_id, pref_soort, pref_waarde dan kan je eenvoudig een nieuwe pref toevoegen. Je staat een nieuwe waarde van pref_soort toe en de pref kan worden vastgelegd.

Het is dus net afhankelijk van de flexibiliteit die je nodig hebt of je tot een extra tabel komt of het met kolommen oplost.

Duidelijk zo?

Op maandag 10 december 2001 21:17 schreef trebel het volgende:
Hoe gaat dat bij GOT?

GoT heeft een preferences tabel en een user tabel, in die preferences tabel staat idd alles uit "prefs" en in die user tabel alles uit "profile".

Precies, het gaat naast een afweging kwa overzichtelijkheid om de afweging tussen snelheid en flexibiliteit (evt. onderhoud).

Jij hebt er over nagedacht, ofnie

Op maandag 10 december 2001 21:39 schreef Ingollus het volgende:
Jij hebt er over nagedacht, ofnie

sorry beetje lame getypt, correxie!

Op maandag 10 december 2001 21:37 schreef ACM het volgende:

[..]

GoT heeft een preferences tabel en een user tabel, in die preferences tabel staat idd alles uit "prefs" en in die user tabel alles uit "profile".

Als ik het goed begrijp per user 1 record in user tabel en 1 record in preference tabel.

Als dit klopt heb je een 1:1 relatie tussen de tabellen.
In een logisch ontwerp kan dit nog, technisch wordt dit altijd op 1 tabel gemapt.

Ik heb bieden gewoon in 1 tabel gedonderd. Werkt goed zo, het is toch niet de bedoeling dat men later via de db gaat rotzooien aangezien alles toch via de software kan

Maar ja ik kan me wel voorstellen dat 2 aparte tabellen overzichtelijker is.

het lijk me eiluk ook wel sneller

User tabel wordt vaker aangesproken dan de prefs tabel, dus als de user tabel kleiner is heb je ook meer snelheid?

denk ik dan...?

Op maandag 10 december 2001 21:48 schreef Tampie2000 het volgende:
User tabel wordt vaker aangesproken dan de prefs tabel, dus als de user tabel kleiner is heb je ook meer snelheid?

Bij mij zou de prefs tabel wordt vaker aangesproken worden als de user tabel.. omdat de prefs vaker opgevraagd worden dan de userinfo, die haal ik 1x op en klaar..

edit: beetje verkeerde nu/toen/dan

Daar heb je dus geen last van als je gewoon een goede index op je user tabel hebt staan.

Consistentie in de DB en onderhoudbaarheid van de code lijken me belangrijker.
Twee tabellen vragen dus om twee inserts bij een nieuwe user en twee deletes bij verwijdering.

Op maandag 10 december 2001 21:27 schreef Goodielover het volgende:

[..]

Snap ik dit? Ergens anders bedoeld??

http://www.mysql.com/doc/S/E/SET.html

set-values worden binair opgeslagen, je kan er dus nog veel leukere zoekopdrachten op uitvoeren...

Op maandag 10 december 2001 21:55 schreef DiSiLLUSiON het volgende:
Bij mij zou de prefs tabel wordt vaker aangesproken worden als de user tabel.. omdat de prefs vaker opgevraagd worden dan de userinfo, die haal ik 1x op en klaar..

Doe je hier niet iets fout?

Het lijkt mij dat je de prefs-tabel alleen aanspreekt bij het inloggen. Dan zet je die zooi in je sessie, en klaar. Misschien dat je hem bij het updaten nog ff nodig hebt, verder niet.

User-tabel gebruik je bij elk topic/forum-overzicht, of geef je niet aan van wie een post/topic is?..

Op maandag 10 december 2001 22:46 schreef PlayR het volgende:
User-tabel gebruik je bij elk topic/forum-overzicht, of geef je niet aan van wie een post/topic is?..

Waarschijnlijk gebeurt dat via een join op geindexeerde kolommen.

Het komt in forum-software trouwens ook nog wel vaak voor dat de username in bijv. de topic-tabel wordt opgeslagen om het mogelijk te maken anoniem te reageren (on-geregistreerd dus).


Verder wordt hier vaak gezegd dat de snelheid achteruit gaat wanneer alles in 1 tabel staan. Dat begrijp ik dus effe niet, is een database-server nou juist niet bedoelt om grote heoveelheden records snel door te kunnen zoeken Waarom zijn we anders van plain-text afgestapt.

Kijk topix-achtige praktijken van het doorzoeken van een tabel met 3.000.000 records kan idd. wat traag gaan, maar zo veel gebruikers zullen zich waarschijnlijk niet aanmelden op een forum (dat zou dus 1 op de 5 nederlanders zijn )

Ik heb het ooit gedaan met twee tabellen, gaat niet goed, moet je de id opzoeken van de ene en die bij de andere er instoppen. Gaat de ene insert verkeerd kun je de prefs table niet vullen bla bla alleen nadelen dus

Op dinsdag 11 december 2001 19:31 schreef freak007 het volgende:

[..]

Het komt in forum-software trouwens ook nog wel vaak voor dat de username in bijv. de topic-tabel wordt opgeslagen om het mogelijk te maken anoniem te reageren (on-geregistreerd dus).

Wat je ook zou kunnen interpreteren als user anoniem, userid=0 ofzo. Kan je tenminste user anonymous renamen naar anoniem.

Om de username op te slaan als apart veld, lijkt mij behoorlijk brak.

Op maandag 10 december 2001 22:46 schreef PlayR het volgende:

[..]

Doe je hier niet iets fout?

Het lijkt mij dat je de prefs-tabel alleen aanspreekt bij het inloggen. Dan zet je die zooi in je sessie, en klaar. Misschien dat je hem bij het updaten nog ff nodig hebt, verder niet.

User-tabel gebruik je bij elk topic/forum-overzicht, of geef je niet aan van wie een post/topic is?..

Zoals Freak007 onder je al zei, bij sommige boards wordt de username etc bij de posttabel opgeslagen, zo ook bij mij.

En de prefs worden bij elke pageview opgevraagd, omdat die nou eenmaal niet in de sessies staan, en aangezien ik toch bij elke pageview de rechten van een gebruik moet checken zit daar gelijk een join bij voor de prefs.. Ik kan de prefs enzo ook in de sessies gooien maargoed dat bekijk ik nog wel ff..

Op dinsdag 11 december 2001 21:02 schreef Nielsz het volgende:

[..]

Wat je ook zou kunnen interpreteren als user anoniem, userid=0 ofzo. Kan je tenminste user anonymous renamen naar anoniem.

Om de username op te slaan als apart veld, lijkt mij behoorlijk brak.

En dat is het ook. Het getuigt van net zoveel intelligentie als het meesturen van de topictitle met een link, omdat men het anders niet voor elkaar kreeg...

Met name vBulletin is hier vreselijk in, met extra data opslaan die niet nodig is... geef mij maar een user 'nul', die niet door de eindgebruiker mee is in te loggen (door na inloggen op if ((int)$userid > 0) te checken voorkom je ook andere ongein)

zoiets?

lijkt me wel geschikt om zo'n query te gebruiken?

(origineel datamodel kwijtgespeeld met serverreinstall dit weekend trouwens )