Heim  >  Artikel  >  Backend-Entwicklung  >  Designprobleme der CRM-Systemstatistiktabelle

Designprobleme der CRM-Systemstatistiktabelle

WBOY
WBOYOriginal
2016-08-18 09:15:391444Durchsuche

Wir arbeiten derzeit an einer CRM-Statistikfunktion und müssen zugehörige Tabellen erstellen, um verschiedene benutzerbezogene Daten zu speichern.
Zum Beispiel: Zählen Sie die Anzahl der Neukunden eines Mitarbeiters an diesem Tag.
Erstens dient eine statistische Tabelle dazu, die Anzahl der täglichen Kunden der Mitarbeiter zu speichern.
Wenn ein Mitarbeiter dann einen Kunden hinzufügt, fügen Sie 1 zum entsprechenden Feld in der Statistiktabelle hinzu. Beim Löschen eines Kunden wird das entsprechende Feld in der Statistiktabelle um 1 reduziert.
Dies löst den Vorgang des Addierens von 1 und Subtrahieren von 1 aus und führt ihn mithilfe von Swoole asynchron aus.

Vor Kurzem ist es notwendig, die Funktion zum Zählen statistischer Daten für diese Woche, diesen Monat, dieses Quartal und dieses Jahr hinzuzufügen.

Ich habe vier Exemplare der [täglichen statistischen Tabelle] kopiert, die der [wöchentlichen statistischen Tabelle], der [monatlichen statistischen Tabelle], der [vierteljährlichen statistischen Tabelle] und der [jährlichen statistischen Tabelle] entsprechen.
Die Datenstrukturen dieser fünf Tabellen sind ähnlich.

Designprobleme der CRM-Systemstatistiktabelle

Meine aktuellen Fragen sind:
1. Ist meine bisherige Methode, asynchrone Triggerung zu verwenden, um die Anzahl der täglichen Kunden von Benutzern zu zählen, optimal? Gibt es einen anderen besseren Weg?
2. Ist es beim Zählen wöchentlicher, monatlicher, vierteljährlicher und jährlicher Daten besser, diese aus der [Tagesstatistiktabelle] zu berechnen, diese vier Tabellen direkt zu erstellen oder asynchrone Triggerung zu verwenden, um relevante Daten direkt zu speichern?

Gibt es einen Experten, der mir eine Antwort geben kann? Vielen Dank

Antwortinhalt:

Wir arbeiten derzeit an einer CRM-Statistikfunktion und müssen zugehörige Tabellen erstellen, um verschiedene benutzerbezogene Daten zu speichern.
Zum Beispiel: Zählen Sie die Anzahl der Neukunden eines Mitarbeiters an diesem Tag.
Erstens dient eine statistische Tabelle dazu, die Anzahl der täglichen Kunden der Mitarbeiter zu speichern.
Wenn ein Mitarbeiter dann einen Kunden hinzufügt, fügen Sie 1 zum entsprechenden Feld in der Statistiktabelle hinzu. Beim Löschen eines Kunden wird das entsprechende Feld in der Statistiktabelle um 1 reduziert.
Dies löst den Vorgang des Addierens von 1 und Subtrahieren von 1 aus und verwendet swoole zur asynchronen Ausführung.

Seit kurzem ist es auch notwendig, die Funktion zum Zählen statistischer Daten für diese Woche, diesen Monat, dieses Quartal und dieses Jahr hinzuzufügen.

Ich habe vier Exemplare der [täglichen statistischen Tabelle] kopiert, die der [wöchentlichen statistischen Tabelle], der [monatlichen statistischen Tabelle], der [vierteljährlichen statistischen Tabelle] und der [jährlichen statistischen Tabelle] entsprechen.
Die Datenstrukturen dieser fünf Tabellen sind ähnlich.

Designprobleme der CRM-Systemstatistiktabelle

Meine aktuellen Fragen sind:
1. Ist meine bisherige Methode, asynchrone Triggerung zu verwenden, um die Anzahl der täglichen Kunden von Benutzern zu zählen, optimal? Gibt es einen anderen besseren Weg?
2. Ist es beim Zählen wöchentlicher, monatlicher, vierteljährlicher und jährlicher Daten besser, diese aus der [Tagesstatistiktabelle] zu berechnen, diese vier Tabellen direkt zu erstellen oder asynchrone Triggerung zu verwenden, um relevante Daten direkt zu speichern?

Gibt es einen Experten, der mir eine Antwort geben kann? Vielen Dank

Wie viele Kunden haben Sie? Wenn es eine Million Levels oder weniger sind und ich es mache, kann ich es einfach in einer Tabelle aufbewahren. Es gibt zwei Felder in der Tabelle, eines heißt created_at und das andere heißt deleted_at, beide vom Typ Datum/Uhrzeit, und dann werden diese beiden Felder indiziert.

Wenn Sie in Zukunft Statistiken erstellen, können Sie diese in Echtzeit abfragen. Die Geschwindigkeit ist unter einer Million Ebenen sehr hoch und Sie können jeden gewünschten Bereich überprüfen. Egal wie viele Daten vorhanden sind, das Hinzufügen eines Caches kann das Leistungsproblem leicht lösen. Es ist zu komplex, dafür viele Tabellen zu erstellen, und der Gewinn überwiegt den Verlust

Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn