Ich arbeite an einer Anwendung, bei der Sie einen Newsletter abonnieren und auswählen können, welche Kategorien Sie abonnieren möchten. Es gibt zwei verschiedene Gruppen von Kategorien: Städte und Kategorien.
Nach dem Senden von E-Mails (was eine geplante Aufgabe ist), muss ich nachsehen, welche Städte und welche Kategorien ein Abonnent abonniert hat, bevor ich die E-Mail sende. Dh, wenn ich "London" und "Manchester" als meine Städte der Wahl abonniert habe und "Essen", "Stoff" und "Elektronik" als meine Kategorien gewählt habe, werde ich nur die Newsletter erhalten, die sich auf diese beziehen.
Die Struktur ist wie folgt:
Auf jedem Newsitem in Umbraco CMS gibt es eine gemeinsame Reihe von Städten und Kategorien (effektiv werden diese als Knoten-IDs gespeichert, da Städte und Kategorien auch Knoten in Umbraco sind) Wenn ich eine oder mehrere Städte und eine oder mehrere Kategorien abonniere Ich speichere die Stadt und die Kategorie nodeids in der Datenbank in benutzerdefinierten Tabellen. Meine relationale Zuordnung sieht folgendermaßen aus:
Und die ganze Struktur sieht so aus:
Für mich sieht das aus wie zwei Sätze von 1 - 1 .. * Relationen (ein Abonnent einer oder mehrerer Städte und ein Abonnent einer oder mehrerer Kategorien)
Um herauszufinden, welche E-Mails an wen gesendet werden, sieht mein Code so aus:
%Vor%Während das funktioniert, mache ich mir etwas Sorgen um die Leistung, wenn eine bestimmte Anzahl von Abonnenten erreicht wird, da wir drei verschachtelte foreach-Loops haben. Auch das Erinnern an meine alten Lehrer predigt: "Für jede for-Schleife gibt es eine bessere Struktur"
Also, ich möchte Ihre Meinung zu der obigen Lösung, gibt es etwas, das hier mit der gegebenen Struktur verbessert werden kann? Und wird es im Laufe der Zeit zu Leistungsproblemen führen?
Jede Hilfe / Hinweis wird sehr geschätzt! : -)
Vielen Dank im Voraus.
Lösung
Nach ein paar guten Stunden des Debuggens und Fummelns bin ich schließlich zu etwas gekommen, das funktioniert (anfangs sah es so aus, als ob mein ursprünglicher Code funktioniert hätte, aber es hat nicht funktioniert)
Leider konnte ich nicht mit LINQ-Abfragen arbeiten, die ich ausprobierte, also ging ich zurück zur "alten" Methode der Iteration ;-) Der endgültige Algorithmus sieht so aus:
%Vor% Zuerst kannst du break
du innerlich foreach sobald shouldBeAdde = true
.
Sie könnten auch LINQ verwenden, aber ich bin mir nicht sicher, ob es schneller sein wird (aber Sie könnten .AsParallel verwenden, um es einfach Multithread zu machen):
%Vor%Das vollständige Denken würde dann auf (einschließlich parallel) kommen:
%Vor%Ich glaube nicht, dass Sie in nächster Zeit Leistungsprobleme haben werden. Ich würde es so lassen, wie Sie es jetzt haben und nur versuchen, zu optimieren, nachdem Sie in ein echtes Leistungsproblem geraten sind und einen Profiler verwendet haben, um zu überprüfen, dass diese Schleifen das Problem sind. Derzeit sieht es so aus, als ob Sie eine vorzeitige Optimierung durchführen.
Nachdem dies gesagt wurde, könnte Folgendes eine mögliche Optimierung sein:
Sie können die Beziehung von Stadt zu Teilnehmer in einem Wörterbuch mit der Stadt als Schlüssel und den Teilnehmern für diese Stadt als Wert des Wörterbuchs speichern, das als HashSet<T>
. Und Sie können das gleiche für die Kategorie zu Abonnenten tun.
Wenn Sie jetzt Ihren Newsletter senden, können Sie die Nachrichten, die Sie mit dem Wörterbuch abrufen können, durchlaufen und die Abonnenten für die Kategorien mit dem Wörterbuch abrufen. Jetzt müssen Sie die Stadt-Abonnenten HashSet mit den Kategorie-Abonnenten HashSet kreuzen und als Ergebnis haben Sie alle passenden Abonnenten für die Nachricht.