требуется предложение по дизайну базы данных

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

Доступны сотни типов продуктов {Name, code}.

Тысячи продавцов заняты продажей этих продуктов {название, код}.

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

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

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

Проблема в том, что ежедневные продажи требуют ввода огромного количества данных. Через пару лет могут быть гигабайты данных (если не терабайты). Если мне нужно показать ежедневные, еженедельные, ежемесячные, ежеквартальные и годовые отчеты о продажах, мне понадобятся различные типы запросов 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. Есть ли способ сломать эту конкретную таблицу, чтобы добиться детализации?


person user366312    schedule 16.11.2009    source источник


Ответы (3)


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


хранимая_модель_01

person Damir Sudarevic    schedule 16.11.2009
comment
+1: хотя обычно я бы не стал заморачиваться с синтетическим ключом на дате, поскольку физическая реализация может включать разделение диапазона по дате, и это обычно проще с естественным ключом. - person David Aldridge; 13.08.2016

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

person Konamiman    schedule 16.11.2009

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

Если только цена не может быть изменена продавцом без каких-либо обоснований в базе данных.

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

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

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

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

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

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

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

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

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

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

person James Black    schedule 16.11.2009
comment
На самом деле меня не волнует количество столбцов. Меня беспокоит количество строк, которые будет содержать таблица после нескольких лет продаж. - person user366312; 16.11.2009
comment
И, кажется, я уже говорил, что меня интересует только таблица DailySales. - person user366312; 16.11.2009
comment
Нужно ли вам сохранять отдельные строки через 5 лет, или вы можете начать агрегировать более старые и оставить все как есть, чтобы вы могли удалить их из таблицы, поскольку они в основном заархивированы? - person James Black; 16.11.2009
comment
@JMSA - я пытался показать, как уменьшить столбцы в таблице DailySales, глядя на то, что уже доступно в других таблицах. - person James Black; 16.11.2009