У меня есть база данных, которая содержит историю продаж продукта. Например, следующая таблица
CREATE TABLE SalesHistoryTable (
OrderID, // Order Number Unique to all orders
ProductID, // Product ID can be used as a Key to look up product info in another table
Price, // Price of the product per unit at the time of the order
Quantity, // quantity of the product for the order
Total, // total cost of the order for the product. (Price * Quantity)
Date, // Date of the order
StoreID, // The store that created the Order
PRIMARY KEY(OrderID));
В таблице будут миллионы транзакций. Отсюда можно создавать профили для продуктов в разных географических регионах (на основе StoreID). Создание этих профилей может занять очень много времени в качестве запроса к базе данных. Например.
SELECT ProductID, StoreID,
SUM(Total) AS Total,
SUM(Quantity) QTY,
SUM(Total)/SUM(Quantity) AS AvgPrice
FROM SalesHistoryTable
GROUP BY ProductID, StoreID;
Приведенный выше запрос может быть использован для получения информации о товарах для любого конкретного магазина. Затем вы можете определить, какой магазин продал больше всего, заработал больше всего денег и продал в среднем больше / меньше. Это было бы очень дорого для использования в качестве обычного запроса в любое время. Каковы некоторые конструктивные решения, чтобы позволить этим типам запросов выполняться быстрее, предполагая, что размер хранилища не является проблемой. Например, я мог бы создать другую таблицу с дублирующейся информацией.
Идентификатор магазина (ключ), идентификатор продукта, общая стоимость, QTY, AvgPrice
И предоставить триггер, чтобы при получении нового заказа запись для этого хранилища обновлялась в новой таблице. Стоимость обновления почти ничего.
Что следует учитывать, учитывая приведенный выше сценарий?