Ansatz zum Filtern aggregierter Daten in Laravel/MySQL 8 erforderlich ⇐ MySql

MySQL DBMS-Forum
Post Reply Previous topicNext topic
Guest
 Ansatz zum Filtern aggregierter Daten in Laravel/MySQL 8 erforderlich

Post by Guest »

Ich hoffe, dass mir hier jemand die richtige Richtung weisen oder einige Ansätze für eine herausfordernde Funktion teilen kann, die ich in meinem Laravel 11-Projekt implementieren muss.
Ich habe ein Modell namens StatisticAggregate, das Datenspalten wie total_submits enthält (z. B. die Häufigkeit, mit der ein Antrag eingereicht werden könnte). Es wird in verschiedene Bereiche/Zeiträume aggregiert, zum Beispiel: stündlich, täglich und wöchentlich.
Ich habe dann die folgenden Hierarchiemodelle, die in der folgenden Reihenfolge ablaufen: Unternehmen, Käufer< /code> dann BuyerTier. Eine Käuferstufe gehört also zu einem Käufer, und ein Käufer gehört zu einem Unternehmen.
Ein Unternehmen könnte zwei Käufer haben, und jeder Käufer könnte zwei Käuferstufen haben.
Wenn ein Antrag eingereicht wird, wird für jeden Zeitraum ein neuer StatisticAggregate-Eintrag erstellt und über a mit einem dieser Modelle verknüpft polymorphe Beziehung:

Code: Select all

Schema::create('statistic_aggregates', function (Blueprint $table) {
$table->ulid('id')->primary();
$table->tinyInteger('for');
$table->tinyInteger('product');
$table->tinyInteger('country');
$table->unsignedInteger('bucket');
$table->mediumInteger('period')->default(60);
$table->morphs('modelable');
$table->char('key_hash', 32)->virtualAs("
MD5(CONCAT(
`for`, '',
`product`, '',
`country`, '',
`bucket`, '',
`period`, '',
`modelable_type`, '',
`modelable_id`, '',
DATE_FORMAT(`bucket_starts_at`, '%Y-%m-%d %H:%i:%s'), '',
DATE_FORMAT(`bucket_ends_at`, '%Y-%m-%d %H:%i:%s')
))
");

$table->bigInteger('total_submits')->default(0);
$table->dateTime('bucket_starts_at');
$table->dateTime('bucket_ends_at');
$table->timestamps();

$table->index('bucket_starts_at'); // For date filtering...
$table->index('bucket_ends_at'); // For date filtering...
$table->index('created_at'); // For fast sorting...
$table->index('key_hash'); // For upserts records...
$table->index('period'); // For period categorisation...

// For duplicate rows...
$table->unique([
'for',
'product',
'country',
'bucket',
'period',
'modelable_type',
'modelable_id',
'bucket_starts_at',
'bucket_ends_at',
'key_hash'
], 'unique_statistic_aggregates_index');
});
Wenn ein einzelner Antrag eingereicht wird, erhalte ich bei stündlichen, täglichen und wöchentlichen Zeiträumen die folgenden Zeilen. Nehmen wir an, dass der Antrag zwei Käufer und zwei Ebenen durchläuft , dann würde das Unternehmen als 2 Submits angezeigt, da es hinter den Kulissen an einem foreach arbeitet, ungefähr so ​​würde es aussehen:

< stark>für: das ist das Berichtstyp-Aufzählung, Produkt: Dies ist die Produkttyp-Aufzählung, Land: Dies ist die Berichtstyp-Aufzählung, Bucket: Unix-Zeitstempel, Periode: Anzahl der Minuten (täglich, stündlich usw.), modellierbar: polymorphes Modell




id
für
Produkt
Land
Bucket
Zeitraum
modelable_type
modelable_type
key_hash
total_submits
bucket_starts_at
bucket_starts_at
created_at
updated_at




01jggwt9rq2zmsr4vvgwdj9643
1
1
1
1736078400
60
App\Models\Company
1
bf2bc2545a4a5f5683d9ef3ed0d977e0
2
2025-01-05 12:00: 0 0 < / t d > < b r / > < t d > 2 0 2 5 - 0 1 - 0 5 1 3 : 0 0 : 0 0 < / t d > < b r / > < t d > 2 0 2 5 - 0 1 - 0 5 1 2 : 0 0 : 0 0 < / t d > < b r / > < t d > 2 0 2 5 - 0 1 - 0 5 1 2 : 0 0 : 0 0 < / t d > < b r / > < / t r > < b r / > < t r > < b r / > < t d > 0 1 j g g w t 9 r q 2 z m s r 4 v v g w d j 9 6 4 4 < / t d > < b r / > < t d > 1 < / t d > < b r / > < t d > 1 < / t d > < b r / > < t d > 1 < / t d > < b r / > < t d > 1 7 3 6 0 3 5 2 0 0 < / t d > < b r / > < t d > 1 4 4 0 < / t d > < b r / > < t d > A p p \ M o d e l s \ C o m p a n y < / t d > < b r / > < t d > 1 < / t d > < b r / > < t d > b f 2 b c 2 5 4 5 a 4 a 5 f 5 6 8 3 d 9 e f 3 e d 0 d 9 7 7 e 0 < / t d > < b r / > < t d > 2 < / t d > < b r / > < t d > 2 0 2 5 - 0 1 - 0 5 0 0 : 0 0 : 0 0 < / t d > < b r / > < t d > 0 5 . 0 1 . 2 0 2 5 2 3 : 5 9 : 5 9 < / t d > < b r / > < t d > 2 0 2 5 - 0 1 - 0 5 0 0 : 0 0 : 0 0 < / t d > < b r / > < t d > 2 0 2 5 - 0 1 - 0 5 0 0 : 0 0 : 0 0 < / t d > < b r / > < / t r > < b r / > < t r > < b r / > < t d > 0 1 j g g w t 9 r q 2 z m s r 4 v v g w d j 9 6 4 5 < / t d > < b r / > < t d > 1 < / t d > < b r / > < t d > 1 < / t d > < b r / > < t d > 1 < / t d > < b r / > < t d > 1 7 3 5 5 1 6 8 0 0 < / t d > < b r / > < t d > 1 0 0 8 0 < / t d > < b r / > < t d > A p p \ M o d e l s \ C o m p a n y < / t d > < b r / > < t d > 1 < / t d > < b r / > < t d > b f 2 b c 2 5 4 5 a 4 a 5 f 5 6 8 3 d 9 e f 3 e d 0 d 9 7 7 e 0 < / t d > < b r / > < t d > 2 < / t d > < b r / > < t d > 2 0 2 4 - 1 2 - 0 1 0 0 : 0 0 : 0 0 < / t d > < b r / > < t d > 05.01.2025 23:59:59
2024-12-01 00:00:00
2024-12-01 00:00:00


01jggwt9rq2zmsr4vvgwdj9646
1
1
1
1736078400
60
App\Models\Buyer
1
bf2bc2545a4a5f5683d9ef3ed0d977e0
1
2025-01-05 12:00:00
05.01.2025 13:00:00
2025-01-05 12:00:00
2025-01-05 12:00:00


01jggwt9rq2zmsr4vvgwdj9647
1
1
1
1736035200
1440
App\Models\Buyer
1
bf2bc2545a4a5f5683d9ef3ed0d977e0
1
2025-01-05 00:00:00
05.01.2025 23:59:59
2025-01-05 00:00:00
2025-01-05 00:00:00


01jggwt9rq2zmsr4vvgwdj9648
1
1
1
1735516800
10080
App\Models\Buyer
1
bf2bc2545a4a5f5683d9ef3ed0d977e0
1
2024-12-01 00:00:00
05.01.2025 23:59:59
2024-12-01 00:00:00
2024-12-01 00:00:00


01jggwt9rq2zmsr4vvgwdj9649
1
1
1
1736078400
60
App\Models\BuyerTier
1
bf2bc2545a4a5f5683d9ef3ed0d977e0
1
2025-01-05 12:00:00
05.01.2025 13:00:00
2025-01-05 12:00:00
2025-01-05 12:00:00


01jggwt9rq2zmsr4vvgwdj9650
1
1
1
1736035200
1440
App\Models\BuyerTier
1
bf2bc2545a4a5f5683d9ef3ed0d977e0
1
2025-01-05 00:00:00
05.01.2025 23:59:59
2025-01-05 00:00:00
2025-01-05 00:00:00


01jggwt9rq2zmsr4vvgwdj9651
1
1
1
1735516800
10080
App\Models\BuyerTier
1
bf2bc2545a4a5f5683d9ef3ed0d977e0
1
2024-12-01 00:00:00
05.01.2025 23:59:59
2024-12-01 00:00:00
2024-12-01 00:00:00


01jggwt9rq2zmsr4vvgwdj9652
1
1
1
1736078400
60
App\Models\Buyer
2
bf2bc2545a4a5f5683d9ef3ed0d977e0
1
2025-01-05 12:00:00
05.01.2025 13:00:00
2025-01-05 12:00:00
2025-01-05 12:00:00


01jggwt9rq2zmsr4vvgwdj9653
1
1
1
1736035200
1440
App\Models\Buyer
2
bf2bc2545a4a5f5683d9ef3ed0d977e0
1
2025-01-05 00:00:00
05.01.2025 23:59:59
2025-01-05 00:00:00
2025-01-05 00:00:00


01jggwt9rq2zmsr4vvgwdj9654
1
1
1
1735516800
10080
App\Models\Buyer
2
bf2bc2545a4a5f5683d9ef3ed0d977e0
1
2024-12-01 00:00:00
05.01.2025 23:59:59
2024-12-01 00:00:00
2024-12-01 00:00:00


01jggwt9rq2zmsr4vvgwdj9655
1
1
1
1736078400
60
App\Models\BuyerTier
2
bf2bc2545a4a5f5683d9ef3ed0d977e0
1
2025-01-05 12:00:00
05.01.2025 13:00:00
2025-01-05 12:00:00
2025-01-05 12:00:00


01jggwt9rq2zmsr4vvgwdj9656
1
1
1
1736035200
1440
App\Models\BuyerTier
2
bf2bc2545a4a5f5683d9ef3ed0d977e0
1
2025-01-05 00:00:00
05.01.2025 23:59:59
2025-01-05 00:00:00
2025-01-05 00:00:00


01jggwt9rq2zmsr4vvgwdj9657
1
1
1
1735516800
10080
App\Models\BuyerTier
2
bf2bc2545a4a5f5683d9ef3ed0d977e0
1
2024-12-01 00:00:00
05.01.2025 23:59:59
2024-12-01 00:00:00
2024-12-01 00:00:00



Das Problem, das ich hier habe, ist, dass mein Frontend einen Bericht als verschachtelte Tabelle mit den folgenden Verschachtelungen anzeigt:
  • Unternehmen

    Käufer

    Käuferstufe
[*]Käufer
  • Käuferstufe



Also wenn ich bin Beim Filtern nach einer bestimmten Käuferstufe ist meine Hauptfrage: Wie subtrahiere ich diese Unternehmenszeile der obersten Ebene oder berechne sie einfach?
Sie enthält die Zahl 2, weil es zwei Einsendungen gab, wird es aggregiert, aber beim Filtern möchte ich nicht manuell die Summe der Käufer neu erstellen und die Unternehmenszeile füllen müssen. Gibt es eine Möglichkeit, etwas zu speichern? eines neuen Modells, das diese effektiv miteinander verbindet um das Delta herauszufinden oder so? Ich betreibe eine Datenbank mit im Wesentlichen etwa 3 Millionen Einträgen pro Tag, daher funktioniert ein aggregierter Ansatz gut für die oberste Ebene, aber wie kann meine total_submits-Spalte beim Filtern wissen, was darin enthalten ist?
Einzelne Zeilen sind wie eine eigene Einheit und kümmern sich hier nicht unbedingt umeinander, aber aus administrativer Sicht wissen wir, dass ein Käufer zu einem Unternehmen gehört. Ich kann nicht einfach fremde ID-Spalten wie „company_id“ haben, weil die Anwendung über eine mandantenfähige globale Logik verfügt
Ich versuche hier nur ein paar Gedanken zu sammeln, also zusammenfassend:< /p>
  • Wenn es eine Modellhierarchie gibt, wie kann ich dann die total_submits-Nummer des Unternehmens-Modells der obersten Ebene zurückverfolgen, um mir einfach das Ergebnis von irgendetwas anzuzeigen? Ich filtere nach? Wenn es 1.000 Einsendungen in dieser Spalte gibt, die programmgesteuert aus mehreren Käufern zusammengestellt worden wären, wie würde ich dann danach filtern?
  • Aggregierte Ansätze wie dieser eignen sich gut für die Filterung auf hoher Ebene, I Sie benötigen eine schnelle Berichterstellung für Millionen von Zeilen
  • Vielleicht gibt es eine Möglichkeit, Dinge miteinander zu verknüpfen?
Top
Post Reply Previous topicNext topic

Quick Reply

Change Text Case: 
   
  • Similar Topics
    Replies
    Views
    Last post

Return to “MySql”