Laatste acties op website weergeven

Pagina: 1
Acties:

Onderwerpen


  • radem205
  • Registratie: Juni 2002
  • Laatst online: 02-02-2022
Hey,

Graag wil ik weten wat jullie advies is over het volgende:
Op een profielensite moet bij elk profiel van elk lid weergegeven worden wat zijn / haar laatste reactie is geweest, dus bijvoorbeeld:

Lid is vriend geworden met *ander lid*
Lid heeft meegedaan met de competitie

Nu is mijn vraag hoe ik dit het beste kan bijhouden voor elk lid. Aangezien, zoals gewoonlijk, alles in aparte tabellen wordt opgeslagen (competitie, vriendschappen) heb ik nog geen idee hoe ik dit ga bewerkstelligen.

Waar ik aan dacht:
- Een tabel aanmaken met alle acties van leden en elke keer wanneer iemand een actie (vrienschap sluiten) doet dit in deze tabel opslaan. Nadeel is dat de data eigenlijk dubbel opgeslagen wordt en het ongedaan maken van acties moeilijk wordt.
- Tabellen verenigen in een query en kijken wat de laatste acties zijn geweest. Lijkt mij de beste oplossing alleen heb geen idee hoe ik dit kan doen.

Graag jullie advies.

  • rvrbtcpt
  • Registratie: November 2000
  • Laatst online: 19-09 16:18
Je kunt ook een view maken in je database van alle acties, dan heb je alles al bij elkaar staan.
Hiervoor moet je wel een query maken. De query die de gegevens ophaalt voor je web interface is dan wel een stuk eenvoudiger.

  • Dorgaldir
  • Registratie: September 2009
  • Laatst online: 10-04 22:52

Dorgaldir

Creature of the web

ik zou persoonlijk gewoon een tabel met logs maken en dan een query dat je zoek op id en sorteert per datum en dan is de log die je wilt de eerste (of laatste, afhankelijk van hoe je sorteert)

Just me


  • radem205
  • Registratie: Juni 2002
  • Laatst online: 02-02-2022
Frijns.Net schreef op donderdag 18 februari 2010 @ 11:26:
Je kunt ook een view maken in je database van alle acties, dan heb je alles al bij elkaar staan.
Hiervoor moet je wel een query maken. De query die de gegevens ophaalt voor je web interface is dan wel een stuk eenvoudiger.
Ok, dat is zeker een optie. Maar uit jouw reactie maak ik op dat het advies is om alle tabellen (met de relevante acties) te verenigen en hier de laatste acties uit de database te halen van elk lid? En dit dan met een view te doen?

Edit: Het nadeel is bij een aparte log dat wanneer iemand een vriendschapsverzoek doet deze nog niet gelogt moet worden. Zodra de andere deze vriendschap accepteert dan moet dus in de log 2 rijen toegevoegd worden (één met: Lid is vriend geworden van *ander lid* en één met: *Ander lid* is vriend geworden met Lid).
En tekstuele wijzigingen in de meldingen zijn naderhand lastiger aan te brengen.

[ Voor 25% gewijzigd door radem205 op 18-02-2010 11:41 ]


  • RobIII
  • Registratie: December 2001
  • Niet online

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

(overleden)
radem205 schreef op donderdag 18 februari 2010 @ 11:32:
Edit: Het nadeel is bij een aparte log dat wanneer iemand een vriendschapsverzoek doet deze nog niet gelogt moet worden. Zodra de andere deze vriendschap accepteert dan moet dus in de log 2 rijen toegevoegd worden (één met: Lid is vriend geworden van *ander lid* en één met: *Ander lid* is vriend geworden met Lid).
En dat is een probleem omdat :?
radem205 schreef op donderdag 18 februari 2010 @ 11:32:
En tekstuele wijzigingen in de meldingen zijn naderhand lastiger aan te brengen.
Dat is maar net hoe je je 'log' tabel maakt. Je kunt natuurlijk ook iets doen als:

date, id_1, id_2 (nullable), action_id

Date = Wanneer
id_1 = lid1 (wie de actie uitvoert)
id_2 = lid2 (wanneer er bevriend wordt bijvoorbeeld)
action_id = Wat is er gedaan

Eventueel nog wat extra velden. En voila. Daarna laat je je view de weergave regelen van de acties. Het voordeel hiervan is dat je een index op id_1 en date kunt zetten waardoor je lekker snel voor een lid de laatste x acties kunt ophalen. Als je een view maakt van een x-tal tabellen die je met een union aan elkaar knoopt en die onderliggende tabellen worden wat groot dan zal de performance (wat) minder zijn.

[ Voor 13% gewijzigd door RobIII op 18-02-2010 11:56 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij


Acties:
  • 0 Henk 'm!

  • radem205
  • Registratie: Juni 2002
  • Laatst online: 02-02-2022
Bedankt voor jullie reacties. Ik denk dat de methode van Rob voor mij de beste methode is.

Maar in navolging op bovenstaande:
Ik wil dat voor een ingelogd lid weergegeven wordt wat zijn / haar vrienden hebben ondernomen op de website (dus eerder genoemde gebeurtenissen).
Nu kan dat waarschijnlijk in 1 query, alleen weet ik niet precies hoe ik dat aan kan pakken.

Ten eerste moeten de vrienden van de ingelogde gebruiker opgehaald worden, waarna wordt gekeken in de gebeurtenissen tabel wat deze vrienden zoal hebben uitgespookt (en deze sorteren op datum (dit is geen probleem)).

Het eerste wat bij mij op komt is gebruik te maken van WHERE lidid1 IN (2,35,23,etc.) OR lidid2 IN (2,35,23,etc.) voor de selectie van de gebeurtenissentabel.

Echter ben ik bang dat dit bij grote aantallen vrienden een performance verlies zal geven.

Kan iemand mij advies geven hoe ik dit het beste kan aanpakken? (het zal wel weer een simpele oplossing zijn, maar ik kom er niet op helaas)

Acties:
  • 0 Henk 'm!

  • JochemK
  • Registratie: Maart 2003
  • Laatst online: 20-09 15:34
radem205 schreef op zaterdag 20 februari 2010 @ 10:17:
...

Echter ben ik bang dat dit bij grote aantallen vrienden een performance verlies zal geven.
Hoe veel vrienden ga je daar verwachten?
Hoeveel performance verlies ben je bang voor?

Acties:
  • 0 Henk 'm!

  • rvrbtcpt
  • Registratie: November 2000
  • Laatst online: 19-09 16:18
Dat ligt er een beetje aan waar je performance verlies verwacht, op de database of bij het uitlezen van je query resultaat?

Je kunt er natuurlijk voor zorgen dat je enkel het laatste x aantal acties laat zien, of die van de laatste week.
Dit levert minder data doorvoer op.
Verder zou je twee views kunnen maken, een die bijvoorbeeld alles laat zien van de laatste week en een die de rest bevat en een groter resultaat teruggeeft.
Wordt de data echt teveel dan zul je met goede indexen moeten werken, database caching, en natuurlijk cleanup van je log tabellen om de zoveel tijd zodat er niet onnodig veel data in blijft staan die toch niemand meer bekijkt.

Als je systeem draait en je hebt scheiding je queries in losse functies staan dan is optimalisatie nog altijd mogelijk. Bekijk eerst maar eens hoe intensief je log tabellen vol lopen en of het wel nodig (interessant) is om alles te loggen

[ Voor 15% gewijzigd door rvrbtcpt op 24-02-2010 13:15 ]

Pagina: 1