Wir suchen nun eine performante Möglichkeit, die es ermöglich das gewünschte Feature umzusetzen.
Dazu habe ich einen alternativen Vorschlag gemacht.
Aber mir persönlich ist dieses Feature relativ egal, da ich es nicht brauche.
Ich kenne nicht die Post pro Zeit und was so gelesen wird pro Zeit.
Ich kann mir nur vorstellen wenn die Forenübersicht aufgerufen wird, das es schneller geht da weniger Tabellen betroffen sind.
Aber dafür müsste man es testen.
dass wir bei jeder Registrierung sofort für 117.000 Themen Dateneinträge erzeugen müssen
Wenn für einen neuer User alle Themen als ungelesen gekennzeichnet sein soll, dann Ja.
Ich würde sagen bei einen neuen User ist für ihn alles als gelesen gekennzeichnet.
Und das Tracking beginnt erst mit der Registrierung.
Zitat von Abt
und gleiches bei neuem Thema für 30.000 User. Hinzu kommt, dass wir Stati erzeugen müssen, die womöglich bei vielen Usern nie wieder abgefragt werden (weil Konten inaktiv etc).
Dem könnte man entgegen wirken, das nur User berücksichtigt werden deren letzte Aktivität nicht zu lange zurück liegt.
Zitat von Abt
Ich weiß nicht, wie das schneller sein soll. Das ist ja gerade das, was wir nicht wollen: expotentielles Wachstum / Leistungsthema. Oder sehe ich das falsch?
Aber wenn ich das richtig sehe mit dem aktuellen Datenbankschema, spielt die Tabelle ForumBoardUserVisits keine Rolle um an die Informationen zu bekommen, ob alle Themen eines Boards gelesen sind.
Und anders müsste die Informationen aus mehreren Tabellen ermittelt werden, neben ForumThreadUserVisits müssten auch noch ForumPosts und ForumThreads berücksichtigt werden.
Bei meinen Vorschlag nur die eine Tabelle.
Weiterhin hat man damit auch die Möglichkeit auszuräumen, z.B. ältere Einträge aus der Tabelle löschen.
Und ich weiß nicht ob es gewünscht ist über die Jahre festzuhalten, wann was von jeden User gelesen wurde.
Ob das wirklich schneller, müsste man testen.
Wenn ich das richtig verstehe wird VisitedOn in ForumThreadUserVisits aktualisiert, wenn ein Thread aufgerufen.
Und das gleiche bei ForumBoardUserVisits, wenn ein Board aufgerufen wird.
Ich weiß nicht wie fix das Datenbankschema ist.
Ich hätte da einen Vorschlag.
Ist es wichtig zu wissen wann eine Thread zuletzt aufgerufen wurde oder reicht es nur zu wissen das für einen User ungelesene vorliegen.
Die Tabellen ForumThreadUserVisits und ForumBoardUserVisits werden durch ForumThreadUserUnread ersetzt.
Diese hat die Spalten UserId, ThreadId und BoardId.
Ist in der Tabelle ein Eintrag vorhanden, bedeutet es liegen ungelesene Post für einen Thread vor.
Wird ein neuer Post (oder auch neuer Thread) erstellt, wird in der Tabelle für alle User ein Eintrag erstellt, wenn noch nicht vorhanden.
Wird von einen User ein Thread aufgerufen, wird ein vorhandenen Eintrag wieder entfernt und man weiß dieser ist gelesen.
Ich greife mal das SQL Fragment von weiter oben auf
SELECT
Id,
BoardName,
(SELECT COUNT(*) FROM ForumThreadUserUnread WHERE UserId = @UserId AND BoardId = Id) AS CountUnreadThread
FROM ForumBoards
JOIN (hier Permission Check)
Ich kann nicht sagen wie Performant das ist, aber nur so als Idee.
Zum Thema DKIM, habe dort mal die Ausgabe detaillierte Fehlerursache aktiviert.
Und erhalte die Meldung Ungültig (SDID Tag hat falsches Format).
Bei anderen gibt es auch die Meldung Interner Fehler.
Hilfreich finde ich immer den ConnectionStringBuilder des entsprechenden ADO.NET Provider und deren Eigenschaften, um zu sehen was der erstellt
Hier wohl SqlConnectionStringBuilder.
Man erhält jetzt ja eine E-Mail die über dem Login informiert.
In dieser E-Mail steht auch eine IP-Adresse, welche nach meinen Verständnis meine öffentliche sein sollte.
Wenn ich es aber richtig sehe ist es die von einem vorgeschalteten Reverse-Proxy (Cloudflare, Inc.)?
Und DKIM Verifier in Thunderbird zeigt an das diese Ungültig (Signatur ist falsch formatiert) ist.
Bei allen hat man das Problem das sich die SQL Dialekte leicht unterscheiden, unabhängig ob man nun
ODBC, OLEDB, ADO und ADO.NET verwendet.
Verwende nicht die direkten Implementierungen der ADO.NET Providern, sondern die Abtraction aus dem Namensraum System.Data.Common
Und für die Erstellung entsprechende die Methoden der Klassen DbProviderFactory und DbProviderFactories.
Im Netzwerk einen eigenen NuGet Server z.B. mit BaGet bereitstellen oder einen lokalen Feed lokal oder einen Share einrichten.
Und die Quelle mit dotnet nuget add source hizufügen.
Die ConnectionStrings können doch auch dynamisch in der Konfiguration hinterlegt.
string domain = ...
string connectionString = configuration.GetValue<string>($"ConnectionStrings:{domain}");
if (string.IsNullOrEmpty(connectionString))
{
// keine Konfiguration für die Domain
}
Ich verstehe es so, die Meldung kommt vom externen Programm für das kein Zugriff auf den Quellcode vorhanden ist. Und dann hilft wohl nur sich an den Entwickler des Programms zuwenden.