gelezen en ongelezen posts op een forum

[peize9]

Hallo Tweakers,

Ik ben bezig met het maken van een klein forum. Ik weet dat het inderdaad simpeler kan door iets te gebruiken dat al gemaakt is, maar het is een leuke oefening voor een beginnend programmeur. Nu gaat het goed, alleen is er een ding waarbij ik geen idee heb hoe ik het zou moeten doen en wat aangeraden word.
Mijn vraag is namelijk hoe ik gelezen en ongelezen post zou moeten maken op een forum. Er zijn veel manieren, maar wat is eigenlijk de beste?

Ik heb een aantal manieren gevonden, maar ik weet niet welke het beste is. Zo kan je een datetime met de laatste login gebruiken om alles wat in de tussentijd gepost is als nieuw te laten zien, dit werkt echter niet optimaal omdat gebruikers waarschijnlijk niet direct alles lezen.

Een andere optie is het maken van een tabel in de database. Maar dit zou een gigantisch lange tabel worden die heel erg veel opslagruimte in neemt. Hoe zouden jullie dit oplossen?

Mvg
Dany

[Radiant]

Datetime van laatste login in combinatie met sessiedata voor de posts die worden gelezen terwijl de gebruiker actief is is een veelgebruikte methode.

[NMe]

peize9 schreef op zondag 19 november 2017 @ 20:08:
Een andere optie is het maken van een tabel in de database. Maar dit zou een gigantisch lange tabel worden die heel erg veel opslagruimte in neemt.

Hoeveel topics en users verwacht je? Tenzij je in de regionen van dit forum komt is zo'n tabel echt niks. Met 1000 users en 10.000 topics zit je nog steeds maximaal aan 10 miljoen records, en dat is echt peanuts voor een beetje database.

[peize9]

NMe schreef op zondag 19 november 2017 @ 21:02:
[...]

Hoeveel topics en users verwacht je? Tenzij je in de regionen van dit forum komt is zo'n tabel echt niks. Met 1000 users en 10.000 topics zit je nog steeds maximaal aan 10 miljoen records, en dat is echt peanuts voor een beetje database.

Ik verwacht zeker geen 1000 users en ook zeker geen 10.000 topics, daarbuiten zal ik waarschijnlijk ook aardig snel automatisch topics laten verwijderen.

Hoeveel ruimte zouden 10 miljoen records precies innemen? Ik wil niet echt een groot deel van mijn opslagruimte in laten nemen voor alleen het gelezen en ongelezen deel.

[ Voor 14% gewijzigd door peize9 op 19-11-2017 21:35 ]

[RobIII]

peize9 schreef op zondag 19 november 2017 @ 21:32:
Hoeveel ruimte zouden 10 miljoen records precies innemen?

Dinsdag! Nee, geel! Nee 11!

Het hangt allereerst natuurlijk af van welk RDBMS (if at all) je gebruikt (aangenomen: MySQL), hoe je tabel er uit ziet (aangenomen: 2 id's), welke datatypes je gebruikt (aangenomen: 2 integers) en wat de overhead per record is in je gekozen RDBMS (en zelfs welk 'row format' in het geval van MySQL). Daarna komt er nog bij kijken of en hoeveel indices je gebruikt, hoe die eruit zien en ga zo maar door.

Kort door de bocht: 10.000.000 x 2 x 4 bytes = 80.000.000 puur-en-alleen voor de rauwe data; daar komt dan nog wat overhead bij. Dus ~80MB minimaal, at best. Dat lijkt me prima te overzien? Voor 1.000 users en 10.000 topics ben je geheid veel meer storage kwijt (aangenomen dat je een beetje een leuk forum hebt, je meer dan een username en wachtwoord van een gebruiker opslaat en meer dan een datum/tijd, titel en inhoud per post opslaat En zélfs dan nog zullen de posts en users tabellen veel meer ruimte, relatief gezien, innemen dan je andere tabelletje).

Having said that: doe eens gek, maak je tabel en indices zoals je denkt dat ze er uit komen zien en vul het met 10 miljoen records en kijk hoeveel ruimte 't je kost Meten == weten en je had je heel de vraag kunnen besparen door gewoon even bovengenoemd in elkaar te flansen en 't uit te proberen; ook al is 't niet 100% bij de realiteit, het geeft je in ieder geval een goede indruk van wat het je ongeveer zou kosten. Het zal je niet verbazen dat die voorgenoemde 80MB niet heel erg realistisch zijn (wegens o.a. ontbreken van overhead in de berekening, laat staan de kosten van de indices); maar (zo uit de duim, natte vinger, op het oog) een 200MB lijkt me dan wél realistisch(er) en zo mogelijk waarschijnlijk zelfs aan de hoge kant (met alle bovengenoemde aannames; ga je er velden bij maken zoals wanneer een post bekeken is etc. dan wordt het een ander verhaal; maar ook dan is 't weer: meten == weten).

peize9 schreef op zondag 19 november 2017 @ 21:32:
daarbuiten zal ik waarschijnlijk ook aardig snel automatisch topics laten verwijderen.

Ja joh, vinden je users leuk! Waarom? Storage kost echt geen drol tegenwoordig... en dat maakt meteen dat ik me afvraag waarom je je überhaupt druk maakt om zo'n tabelletje. Zélfs zonder bovenstaande informatie moet je toch kunnen zien dat deze tabel, relatief gezien, geen drol kost (storage-wise) t.o.v. de posts tabel bijvoorbeeld? De afweging(en) die je éérst zou moeten maken voordat je je hierover bekommert is: hoe belangrijk vinden we deze functionaliteit, is het de ontwikkeltijd waard (ontwerp + uitvoering), hoeveel gaan we er mee "winnen" etc. Standaard kosten/baten plaatje dus; en dan komen de kosten van die storage ergens in de kantlijn te staan bij dat plaatje dunkt me zo.

[ Voor 48% gewijzigd door RobIII op 19-11-2017 22:01 ]

[peize9]

RobIII schreef op zondag 19 november 2017 @ 21:43:
[...]

Dinsdag! Nee, geel! Nee 11!

Het hangt allereerst natuurlijk af van welk RDBMS (if at all) je gebruikt (aangenomen: MySQL), hoe je tabel er uit ziet (aangenomen: 2 id's), welke datatypes je gebruikt (aangenomen: 2 integers) en wat de overhead per record is in je gekozen RDBMS (en zelfs welk 'row format' in het geval van MySQL). Daarna komt er nog bij kijken of en hoeveel indices je gebruikt, hoe die eruit zien en ga zo maar door.

Kort door de bocht: 10.000.000 x 2 x 4 bytes = 80.000.000 puur-en-alleen voor de rauwe data; daar komt dan nog wat overhead bij. Dus ~80MB minimaal, at best. Dat lijkt me prima te overzien? Voor 1.000 users en 10.000 topics ben je geheid veel meer storage kwijt (aangenomen dat je een beetje een leuk forum hebt, je meer dan een username en wachtwoord van een gebruiker opslaat en meer dan een datum/tijd, titel en inhoud per post opslaat En zélfs dan nog zullen de posts en users tabellen veel meer ruimte, relatief gezien, innemen dan je andere tabelletje).

Having said that: doe eens gek, maak je tabel en indices zoals je denkt dat ze er uit komen zien en vul het met 10 miljoen records en kijk hoeveel ruimte 't je kost Meten == weten en je had je heel de vraag kunnen besparen door gewoon even bovengenoemd in elkaar te flansen en 't uit te proberen; ook al is 't niet 100% bij de realiteit, het geeft je in ieder geval een goede indruk van wat het je ongeveer zou kosten. Het zal je niet verbazen dat die voorgenoemde 80MB niet heel erg realistisch zijn (wegens o.a. ontbreken van overhead in de berekening, laat staan de kosten van de indices); maar (zo uit de duim, natte vinger, op het oog) een 200MB lijkt me dan wél realistisch(er) en zo mogelijk waarschijnlijk zelfs aan de hoge kant (met alle bovengenoemde aannames; ga je er velden bij maken zoals wanneer een post bekeken is etc. dan wordt het een ander verhaal; maar ook dan is 't weer: meten == weten).


[...]

Ja joh, vinden je users leuk! Waarom? Storage kost echt geen drol tegenwoordig... en dat maakt meteen dat ik me afvraag waarom je je überhaupt druk maakt om zo'n tabelletje. Zélfs zonder bovenstaande informatie moet je toch kunnen zien dat deze tabel, relatief gezien, geen drol kost (storage-wise) t.o.v. de posts tabel bijvoorbeeld? De afweging(en) die je éérst zou moeten maken voordat je je hierover bekommert is: hoe belangrijk vinden we deze functionaliteit, is het de ontwikkeltijd waard (ontwerp + uitvoering), hoeveel gaan we er mee "winnen" etc. Standaard kosten/baten plaatje dus; en dan komen de kosten van die storage ergens in de kantlijn te staan bij dat plaatje dunkt me zo.

klopt helemaal. Sowieso, 80mb is idd niets, en ik heb idd gekeken, storage kost echt helemaal niets. Dus dan word het maar mooi een grote tabel bedankt allen.

[Hydra]

Voor gebruikers zijn welke topics ze 'gelezen' hebben alleen relevant voor topics van de laatste tijd, dus storage is een non-issue. Daarnaast is het ook slechts een koppeltabel tussen user-id en topic-id met daarbij een timestamp. Dat stelt niks voor.

Daarnaast; ga altijd voor de beste oplossing en ga dan, indien nodig, optimaliseren voor snelheid of opslagruimte. Je zult vaak zien dat het helemaal niet nodig is.

[MrFancyPantss]

RobIII schreef op zondag 19 november 2017 @ 21:43:
[...]
aangenomen dat je een beetje een leuk forum hebt, je meer dan een username en wachtwoord van een gebruiker opslaat en meer dan een datum/tijd, titel en inhoud per post opslaat
[...]

Sla aub nooit username/pw zelf op, zelfs niet gehasht. Laat dat aan de professionals over. Meeste mensen gebruiken zelfde user/pw voor elke toepassing, wat in een online dictionary terecht kan komen voor dictionary attacks, als je db gehackt wordt. En zo te horen is dit een klein project van een beginnend developer, dus dit behoort zeker tot de mogelijkheden . Als je met accounts werkt en je wil niet zitten knoeien met je eigen sts op te zetten en te hosten, gebruik dan een third party identity provider, zoals bv Auth0. Simpele plugin te integreren in je applicatie, goede tutorials en je moet je nooit iets aantrekken van passwords.

[RobIII]

MrFancyPantss schreef op dinsdag 21 november 2017 @ 17:13:
Sla aub nooit username/pw zelf op

Ja, helemaal mee eens maar ook compleet offtopic en irrelevant hier. Het ging hier om de hoeveelheid data (t.o.v. andere data) en niet om wélke data

[MrFancyPantss]

True, volledig off topic, maar wel belangrijk om beginnende devers te leren imo