Мобильная версияУ меня есть модель под названием StatisticAggregate, который содержит столбцы данных, такие как total_submits (например, сколько раз можно было подать заявку). Они агрегируются по разным сегментам/периодам, например: почасово, ежедневно и еженедельно.
Затем у меня есть следующие модели иерархии, которые идут в следующем порядке: Компания, Покупатель< /code>, затем уровень покупателя. Таким образом, уровень BuyerTier принадлежит покупателю, а покупатель принадлежит компании.
У компании может быть 2 покупателя, и у каждого покупателя может быть два уровня покупателя.
При отправке заявки она создает новую запись StatisticAggregate для каждого периода и ссылается на одну из этих моделей через полиморфная связь:
Код: Выделить всё
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');
});
< Strong>для: это перечисление типа отчета, product: это перечисление типа продукта, country: это перечисление типа отчета, ведро: временная метка unix , период: количество минут (ежедневно, ежечасно и т. д.), моделируемый: полиморфная модель
id
для
продукт
страна
сегмент
период
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
05.01.2025 12:00: 00
05.01.2025 13:00:00
05.01.2025 12:00:00
05.01.2025 12:00:00
01jggwt9rq2zmsr4vvgwdj9644
1
1
1
1736035200
1440
App\Models\Company
1
bf2bc2545a4a5f5683d9ef3ed0d977e0
2
2025-01-05 00:00:00
2025-01-05 23:59:59
2025-01-05 00:00:00
2025-01-05 00:00:00
01jggwt9rq2zmsr4vvgwdj9645
1
1
1
1735516800
10080
Приложение\Модели\Компания
1
bf2bc2545a4a5f5683d9ef3ed0d977e0
2
01.12.2024 00:00:00
2025-01-05 23:59:59
2024-12-01 00:00:00
2024-12-01 00:00:00
01jggwt9rq2zmsr4vvgwdj9646
1
1
1
1736078400
60
Приложение\Модели\Покупатель
1
bf2bc2545a4a5f5683d9ef3ed0d977e0
1
05.01.2025 12:00:00
2025-01-05 13:00:00
05.01.2025, 12:00:00
05.01.2025, 12:00:00
01jggwt9rq2zmsr4vvgwdj9647
1
1
1
1736035200
1440
Приложение\Модели\Покупатель
1
bf2bc2545a4a5f5683d9ef3ed0d977e0
1
05.01.2025 00:00:00
2025-01-05 23:59:59
2025-01-05 00:00:00
2025-01-05 00:00:00
01jggwt9rq2zmsr4vvgwdj9648
1
1
1
1735516800
10080
Приложение\Модели\Покупатель
1
bf2bc2545a4a5f5683d9ef3ed0d977e0
1
01.12.2024 00:00:00
2025-01-05 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
05.01.2025 12:00:00
2025-01-05 13:00:00
05.01.2025, 12:00:00
05.01.2025, 12:00:00
01jggwt9rq2zmsr4vvgwdj9650
1
1
1
1736035200
1440
App\Models\BuyerTier
1
bf2bc2545a4a5f5683d9ef3ed0d977e0
1
05.01.2025 00:00:00
2025-01-05 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
01.12.2024 00:00:00
2025-01-05 23:59:59
2024-12-01 00:00:00
2024-12-01 00:00:00
01jggwt9rq2zmsr4vvgwdj9652
1
1
1
1736078400
60
Приложение\Модели\Покупатель
2
bf2bc2545a4a5f5683d9ef3ed0d977e0
1
05.01.2025 12:00:00
2025-01-05 13:00:00
05.01.2025, 12:00:00
05.01.2025, 12:00:00
01jggwt9rq2zmsr4vvgwdj9653
1
1
1
1736035200
1440
Приложение\Модели\Покупатель
2
bf2bc2545a4a5f5683d9ef3ed0d977e0
1
05.01.2025 00:00:00
2025-01-05 23:59:59
2025-01-05 00:00:00
2025-01-05 00:00:00
01jggwt9rq2zmsr4vvgwdj9654
1
1
1
1735516800
10080
Приложение\Модели\Покупатель
2
bf2bc2545a4a5f5683d9ef3ed0d977e0
1
01.12.2024 00:00:00
2025-01-05 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
05.01.2025 12:00:00
2025-01-05 13:00:00
05.01.2025, 12:00:00
05.01.2025, 12:00:00
01jggwt9rq2zmsr4vvgwdj9656
1
1
1
1736035200
1440
App\Models\BuyerTier
2
bf2bc2545a4a5f5683d9ef3ed0d977e0
1
05.01.2025 00:00:00
2025-01-05 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
01.12.2024 00:00:00
2025-01-05 23:59:59
2024-12-01 00:00:00
2024-12-01 00:00:00
Проблема, с которой я столкнулся, заключается в том, что мой интерфейс показывает отчет в виде вложенной таблицы со следующими вложениями:
- Компания
Покупатель
Уровень покупателя
- Уровень покупателя
Поэтому, когда я фильтрую по определенному уровню покупателя, мой основной вопрос заключается в том, как мне вычесть или просто вычислить эту строку компании верхнего уровня?< /strong>
Он содержит номер 2, поскольку было 2 отправки, он агрегируется, но при фильтрации я не хочу вручную перебирать и перестраивать сумму покупателей и заполнить строку компании, есть ли как я могу сохранить какую-то новую модель, которая эффективно объединяет их, чтобы вычислить дельту или что-то в этом роде? Я использую базу данных с примерно 3 миллионами записей в день, поэтому агрегированный подход хорошо работает для верхнего уровня, но при фильтрации как мой столбец total_submits может узнать, что в него пошло?
Отдельные строки представляют собой отдельный объект и здесь не особо заботятся друг о друге, но с точки зрения функциональности с точки зрения администратора мы знаем, что покупатель принадлежит компании. Я не могу просто использовать столбцы с внешними идентификаторами, такие как Company_id, потому что приложение имеет глобальную логику мультиарендного типа.
Просто пытаюсь высказать некоторые мысли, чтобы подвести итог:< /p>
- При наличии иерархии модели, как я могу вернуться к этому номеру компании верхнего уровня модели total_submits, чтобы просто показать мне результат чего угодно Я фильтрую? Если в этом столбце 1000 заявок, которые были бы программно составлены от нескольких покупателей, как бы я отфильтровал это?
- Подобные агрегированные подходы хорошо работают для фильтрации высокого уровня, я нужны быстрые отчеты для миллионов строк.
- Может быть, есть способ связать вещи вместе?
Подробнее здесь: https://stackoverflow.com/questions/793 ... el-mysql-8
