Вопросы проектирования баз данных о дублирующейся информации

Question

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

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; 

Вышеприведенный запрос может быть использован для получения информации на основе продуктов для любого конкретного магазина. Тогда вы могли бы определить, какой магазин продал больше всего, сделал больше денег и в среднем продает в основном/наименее. Это было бы очень дорого использовать в качестве обычного запроса в любое время. Каковы некоторые дизайнерские решения, позволяющие запускать эти типы запросов быстрее при условии, что размер хранилища не является проблемой. Например, я мог бы создать другую таблицу с дублирующейся информацией. Идентификатор магазина (ключ), идентификатор продукта, TotalCost, QTY, AvgPrice И предоставить триггер, чтобы при получении нового заказа запись для этого магазина обновляется в новой таблице. Стоимость обновления почти ничего.

Что следует учитывать при использовании приведенного выше сценария?

Answer 1

Обычно это то, что вы использовали бы для хранилища данных, но, кроме этого, использование триггера для обновления второй таблицы является вполне жизнеспособным вариантом.

У вас также может быть вторая таблица, заполняемая пакетным заданием на периодической основе (дополнительная опция для хранения данных, такая как опция). Вы также можете использовать материализованное представление, если ваша база данных поддерживает их.

Answer 2

Я бы рассмотреть:

• хранилища данных/OLAP решение
• (как вы сказали) запускать интеллектуальный анализ данных запросов к отдельным предвычисленным таблицам/набор данных
• индексируются/материализованные представлениями, который почти такой же, как в предыдущем пункте

Есть некоторые вопросы, хотя:

• Вы ожидаете данные в реальном времени?
• Какой у вас объем записи?
• какой двигатель DB?

Answer 3

Возможно, вы захотите ознакомиться с использованием materialized views, который будет запрашиваться только периодически.

Answer 4

«Стоимость обновления почти ничего».

За исключением того, что все обновления должны быть сериализованы. Потому что, несмотря ни на что, древний закон физики по-прежнему остается тем, что в одном месте одновременно нет двух вещей.