Вычисление счетов по нескольким столбцам в DB

Question

У нас есть продукт, поддерживаемый БД (в настоящее время Oracle, планирующий поддержку MS SQL Server) с несколькими десятками таблиц. Для простоты возьмем одну таблицу под названием TASK.

У нас есть прецедент, когда нам нужно представить пользователю количество задач, имеющих конкретные критерии. Например, предположим, что среди многих столбцов таблицы задача, есть 3 колонки, подходящие для этого случая использования:

• возможные значения приоритетами LOW, средняя, ​​высокая
• ВЛАДЕЛЕЦ - возможные значения зарегистрированных пользователей в система (может быть 10s)
• СТАТУС возможные значения IDLE, IN_PROCESS, СДЕЛАНО

Таким образом, мы хотим показать пользователю, сколько именно задачи LOW, MEDIUM, HIGH, как многие из них принадлежат некоторые конкретный пользователь и сколько из них относятся к различным статусам. Разумеется, основная реализация заключалась бы в том, чтобы поддерживать эти подсчеты в актуальном состоянии при каждой модификации таблицы TASK. Однако то, что усложняет вопрос, заключается в том, что пользователь может дополнительно фильтровать результат по некоторым критериям, которые могут включать (или не) часть столбцов, упомянутых выше.

Например, использование может хотеть видеть эти подсчеты только для задач, которые принадлежат ему и были созданы в прошлом месяце. Количество возможных комбинаций фильтров здесь бесконечно, поэтому бессмысленно утверждать, что поддержание современных показателей невозможно.

Итак, вопрос в том, как решить эту проблему без серьезного влияния на производительность БД? Может ли это быть разрешено исключительно по БД, или мы должны прибегать к использованию других хранилищ данных, таких как редкий хранилище данных? Это похоже на проблему, которая присутствует во многих компаниях. Например, в магазине Amazon вы можете видеть подсчеты по категориям, используя критерии произвольного текстового поиска, а это значит, что они также рассчитывают его на месте, а не постоянно обновляют его.

Последнее: мы можем принять определенное функциональное ограничение, заявив, что счет должен быть точным до 100, но начиная с 100 он может просто сказать «более 100 задач». Возможно, это смягчение может позволить нам генерировать более эффективные SQL-запросы.

Спасибо!

Answer 1

Как я понимаю, вы хотели бы иметь информацию о 3 разных дистрибутивах: через ПРИОРИТЕТ, ВЛАДЕЛЕЦ и СОСТОЯНИЕ. Я полагаю, что лучший способ решить эту проблему - поддерживать 3 разных источника данных (например, SQL-запрос, агрегированную информацию в БД или Redis и т. Д.).

Простейший способ расчета этих данных. Я вижу, как строят отдельный SQL-запрос для каждого дистрибутива. Например, для приоритета было бы что-то вроде:

SELECT USER_ID, PRIORITY, COUNT(*) 
FROM TASKS 
[WHERE <additional search criterias>] 
GROUP BY PRIORITY 

Конечно, это не самый эффективный способ с точки зрения производительности базы данных, но это позволяет поддерживать отсчеты в актуальном состоянии.

Если вы хотите сохранить агрегированные значения, которые могут значительно снизить нагрузку на базу данных (это зависит от количества строк), вам, вероятно, потребуется построить куб, для которых должны быть доступны критерии поиска. При таком подходе вы можете реализовать функциональность ограничения.