Ein "Protokoll" neuer (distinkter) Ereignisse in einer Datenbank anzeigen

Question

Ich habe eine Anwendung, die mehrere nicht verwandte Tabellen in ihrer Datenbank hat. Ich werde das erklären, indem ich eine "automatisch aktualisierende" Version der SO-Homepage als Beispiel benutze, also sagen wir, ich habe die Tabellen "Benutzer", "Kommentare" und "Fragen".

Die Homepage-Client-Seite muss regelmäßig den Server abfragen und ein Protokoll über alle neuen "Ereignisse" erhalten, die aufgetreten sind. Das heißt, ich möchte (irgendwie) die neuen Fragen, Kommentare und Benutzer anzeigen, die seit der letzten Umfrage zu SO hinzugefügt wurden.

Auf dem Weg wäre einfach eine Variable auf der Client-Seite zu halten, die den letzten Index jeder meiner Tabellen enthält, senden Sie es an den Server, und der Server sendet mir die neuen Benutzer, Kommentare und Fragen.

Das Problem ist, was passiert, wenn ich eine neue Art von Informationen, sagen wir, Stimmen hinzufügen. Jetzt muss ich eine andere Variable auf der Client-Seite speichern, und der Server muss eine andere Tabelle abfragen. Und so weiter, für jede neue Art von Information, die ich behalte.

Ich bin auf der Suche nach einer Lösung, die mir hilft, dies zu vermeiden.

Ein weiteres Problem - sagen wir, ich würde gerne alle "Ereignisse" sehen, die seit dem letzten Mal passiert sind, aber danach sortiert, wann sie stattgefunden haben.

Eine Richtung, die ich hatte, ist eine einzige "Ereignisse" -Tabelle zu haben, die die Information darüber enthält, wann jedes Ereignis passiert ist. Ich kann dann nur diese Tabelle abfragen und eine Liste aller neuen Ereignisse abrufen. Das Problem ist, dass jedes Ereignis ziemlich unterschiedlich ist (ein neuer Kommentar hat andere Spalten als eine neue Upvote, etc.). Ich bin mir also nicht sicher, wie ich das umsetzen soll oder ob das überhaupt eine gute Idee ist.

Hat jemand irgendwelche Ideen, wie ich das lösen kann? Dies scheint etwas zu sein, was viel auftauchen würde, aber ich habe leider nicht wirklich viel Erfahrung mit Datenbanken.

Danke!

Answer 1

Es klingt für mich wie Sie versuchen, zukunftssicher über Datenbank-Design. Während dies durch etwas getan werden kann, warne ich davor, weil der Wert, den es addiert, dazu tendiert, die Kosten nicht wert zu sein.

Stattdessen sollten Sie die Datenbank so realitätsnah wie möglich modellieren und nicht wie Sie beabsichtigen, sie zu verwenden.

Verwenden Sie dann SQL, um die Daten so zu projizieren, wie Sie sie benötigen. Sie können dies durch Anweisungen tun, die entweder die Metadaten liefern, die Sie benötigen, z.

Oder (und dies nicht oft genug benutzt bekommt)

Zurück mehr als eine Ergebnismenge aus Ihrer Datenbank in einem Rutsch

Select 
    userid, 
    ComentText 
From 
    Comments 
Where 
     lastUpdate > #InputParamter1#; 
Select 
    userId, 
    Questions, 
    Tags 
From 
    Questions 
Where 
     lastUpdate > #InputParamter1# 

Das heißt Sie werden immer noch schreiben einige Code, wenn Sie neue Sachen hinzufügen, aber es sollte auf die Aktualisierung Ihrer SQL beschränkt werden, Hinzufügen neuer Container für Ihre Daten und dann Code zur Anzeige an die Endbenutzer und dann zu validieren und zu speichern.

Ehrlich gesagt, die Idee, neue Sachen hinzuzufügen, die etwas Arbeit erfordern, scheint mir nicht so schrecklich zu sein.