необходимо проектирование базы данных

Question

Мне нужно оформить стол для ежедневных продаж фармацевтической продукции.

Существуют сотни типов продуктов {Имя, код}.

Для продажи этих продуктов работают тысячи продавцов {имя, код}.

Они собирают товары из разных складов {имя, код}.

Они работают в разных областях -> Зоны -> Рынки -> Торговые точки и т. Д. {У всех есть имена и коды}

Каждый товар имеет различные типы цен {Цена производства, Цена сделки, Цена бизнеса, Цена со скидкой и т. Д.}. И продавцы могут свободно выбирать из этой комбинации, чтобы оценить цену продажи.

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

Это мой первоначальный дизайн:

Product {ID, Code, Name, IsActive}
ProductXYZPriceHistory {ID, ProductID, Date, EffectDate, Price, IsCurrent}
SalesPerson {ID, Code, Name, JoinDate, and so on..., IsActive}
SalesPersonSalesAraeaHistory {ID, SalesPersonID, SalesAreaID, IsCurrent}
Depot {ID, Code, Name, IsActive}
Outlet {ID, Code, Name, AreaID, IsActive}
AreaHierarchy {ID, Code, Name, PrentID, AreaLevel, IsActive}
DailySales {ID, ProductID, SalesPersonID, OutletID, Date, PriceID, SalesPrice, Discount, etc...}

Теперь, кроме индексации, как я могу нормализовать мою таблицу DailySales, чтобы иметь мелкозернистый дизайн, который мне не нужно будет менять в течение последующих лет?

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

Мне не нужен подробный совет по проектированию . Мне просто нужен совет, касающийся только таблицы DailySales. Есть ли способ разбить эту конкретную таблицу для достижения детализации?

Answer 1

То, что вы ищете, называется хранилищем данных (DW). Я предлагаю вам взглянуть на «Инструментарий хранилища данных» Ральфа Кимбалла - там приведены примеры проектов хранилищ данных для розничных продаж. Вот очень упрощенный (первый вариант) пример того, как это может выглядеть. Вы заметите, что это ненормализованная структура, оптимизированная для отчетности и анализа. Фактором таблицы фактов обычно является один пункт (строка) в квитанции. Надеюсь, что это указывает на ваше решение. Несколько терабайт для DW в порядке.

Answer 2

Если вы собираетесь генерировать огромные объемы данных и вам необходимо создавать отчеты на основе прошлых данных, вам следует рассмотреть возможность использования механизма Business Intelligence . Обычно эти механизмы позволяют архивировать исторические данные в отдельном хранилище данных (чтобы не загромождать базу данных ежедневной работы), но при этом получать статистические данные и отчеты из архивных данных.

Answer 3

Почему бы не назначить дату и цену для продукта, чтобы вы могли сбросить цену из таблицы dailysales, поскольку вы можете получить ее, присоединившись.

Если цена не может быть изменена продавцом без объяснения причин в базе данных.

В определенный день продавец может находиться только в одной торговой точке? Если так, то вы можете бросить аутлетид.

У вас есть PriceiD, SalesPrice и Скидка. Если я знаю идентификатор скидки и торговой точки, а также первоначальную цену, я могу определить налоги и рассчитать SalesPrice, чтобы вы могли отказаться от этого.

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

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

Вы захотите извлечь информацию из нее в промежуточные таблицы по дням / месяцам / годам, например, чтобы упростить агрегацию данных по дате, чтобы ваши отчеты создавались быстрее.

В вашем вопросе много неизвестных, но, надеюсь, это поможет.

Обновление: На основании комментария

У меня была таблица, в которой содержалась информация об использовании ресурсов кем-то, и эта таблица быстро увеличивалась. Итак, мы решили, что мы будем хранить только 2 или 3 года данных, а остальные будут агрегированы, а необработанные данные будут выгружены в файл для архивных целей.

При рассмотрении количества строк вам нужно будет решить, сколько данных вам нужно сохранить, и как вы можете архивировать старые данные, чтобы сделать их доступными, если они абсолютно необходимы, но вы можете создавать отчеты это должно быть необходимо заранее.

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