Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Проектирование БД Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 Помогите довести до ума модель данных склада  [new]
mkr
Member

Откуда: Беларусь, Брест
Сообщений: 99
Делал когда-то простенькую модель склада

Приход сырья (бумага):
CREATE TABLE WP_SUPPLY_ROLLS (
    ID             INTEGER NOT NULL,
    EXT_NO         VARCHAR(20),
    WEIGHT         NUMERIC(5,0) NOT NULL,
    PAPER          INTEGER NOT NULL,
    REST           NUMERIC(7,2)
);

при добавлении рулона бумаги, остаток становится равным весу рулона

склад сбрасывает рулоны на расход добавляя рулон в "промежуточную" табличку
CREATE TABLE WP_ROLLS_OUT (
    ID           INTEGER NOT NULL,
    ROLL_NO      INTEGER NOT NULL,
    WHO_ADD      VARCHAR(25) DEFAULT current_user NOT NULL,
    CREATED      TIMESTAMP DEFAULT current_timestamp NOT NULL,
);


когда рулон используем в производстве, добавляем его в соотв. табличку (из WP_ROLLS_OUT)
CREATE TABLE WP_ROLLS_SHIFT (
    ID           INTEGER NOT NULL,
    ROLL_NO      INTEGER NOT NULL,
    USED_WEIGHT  NUMERIC(7,2) NOT NULL,
    WRITE_OFF    INTEGER NOT NULL,  //списание рулона
    SHIFT        INTEGER NOT NULL
);

при добавлении рулона в смену, его остаток в таблице WP_SUPPLY_ROLLS через триггеры автоматом уменьшается на
величину USED_WEIGHT
*write_off - если 1 рулон списан целиком (выставляется вручную)

сейчас всё чудно работает:
что висит на расходе склада - выборка из WP_ROLLS_OUT за исключение тех рулонов, что есть в WP_ROLLS_SHIFT (NOT IN)

приход сырья - Суммируем вес WP_SUPPLY_ROLLS и группируем по бумаге
остаток - выборка из WP_SUPPLY_ROLLS за исключение тех рулонов, что есть в WP_ROLLS_SHIFT (NOT IN)
расход - ищем первое вхождение рулона в WP_ROLLS_SHIFT (первая смена в котором использовался рулон)

есть ещё понятие остатков бумаги на производстве (так же как и рулоны на расходе, но с доп. условиями):
(выборка из WP_ROLLS_OUT за исключение тех рулонов, что есть в WP_ROLLS_SHIFT) AND (вес рулона <> остаток)
AND (WRITE_OFF <> 0) 


чую, что получился велосипед))

подскажите, как упростить модель с точки зрения исключения или оптимизации постоянно используемых мною запросов NOT IN (WP_ROLLS_SHIFT)
быть может какие-то best practices складского учёта :)

p.s. к этой теме вернулся из-за того, что нужно выводить остатков бумаги на производстве на каждый день, что выльется в огромную кучу условий
5 июн 17, 15:34    [20540692]     Ответить | Цитировать Сообщить модератору
 Re: Помогите довести до ума модель данных склада  [new]
Кот Матроскин
Member

Откуда: Москва
Сообщений: 7569
Если смотреть на Вашу схему -
не очень понятно, зачем Вам условие NOT IN WP_ROLLS_SHIFT.
Почему бы сразу не выкидывать рулон из WP_ROLLS_OUT, если он начал расходоваться?
Когда Вам нужна выборка из WP_ROLLS_OUT включая те, которые есть в WP_ROLLS_SHIFT?

best practices безусловно есть, и они мало похожи на Ваши :)
Я бы советовал для начала постараться свести бизнес-процессы к двум операциям "приход" и "списание", не пытаясь создавать какие-то дополнительные сущности.
Скажем, бизнес-процесс "сбрасывает рулоны на расход" я бы попробовал описать как "списание с основного склада" + "приход на виртуальный склад-производство".
"используется в производстве" = "списание с виртуального склада-производства".
Если это получится - можно задуматься о том, как хранить остатки так, чтобы эти операции
эффективно создавались и учитывались
Если некий бизнес-процесс совсем, ну совсем никак не ложится на эти 2 операции- ну тогда надо уже задумываться "а не завести ли новую сущность".
5 июн 17, 17:02    [20541030]     Ответить | Цитировать Сообщить модератору
 Re: Помогите довести до ума модель данных склада  [new]
mkr
Member

Откуда: Беларусь, Брест
Сообщений: 99
Кот Матроскин,
автор
зачем Вам условие NOT IN WP_ROLLS_SHIFT.

пока рулон не использовался - он на складе

автор
Почему бы сразу не выкидывать рулон из WP_ROLLS_OUT

изначально думал чистить по прошествии некоторого времени или удалять сразу, но не определился и оставил)

автор
Когда Вам нужна выборка из WP_ROLLS_OUT включая те, которые есть в WP_ROLLS_SHIFT?

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

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


приход понятен - внесли данные накладной и делов.
"списание с основного склада" -> "приход на виртуальный склад-производство" как раз и реализуется через WP_ROLLS_OUT, т.к. склад и производство - это разные подразделения (это раз), принимая рулон, оператору на производстве проще выбрать рулон из маленького списка (который подготовил склад), чем из огромного общего (это два)

"используется в производстве" = "списание с виртуального склада-производства" - если рулон использован до конца - его списываем сразу, а вот если на нём остался остаток - вот тогда он болтается... при том, что его остаток висит на самом рулоне (для того, чтобы вывести остатки на определённую дату - получается ни то ни сё)
5 июн 17, 17:34    [20541128]     Ответить | Цитировать Сообщить модератору
 Re: Помогите довести до ума модель данных склада  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 43632

mkr
пока рулон не использовался - он на складе

Физически? Не верю. Что это за производство/станок, который способен жрать бумагу прямо из
рулона, лежащего на складе?

Posted via ActualForum NNTP Server 1.5

5 июн 17, 17:49    [20541153]     Ответить | Цитировать Сообщить модератору
 Re: Помогите довести до ума модель данных склада  [new]
bideveloper
Member

Откуда:
Сообщений: 105
mkr,
например, best practices на основе Microsoft Dynamics (упрощенно):

Есть таблица складских транзакций inventtrans c полями
Дата транзакции (дата прихода расхода)
Номенклатура (бумага)
Аналитика (склад, номер рулона)
Тип транзакции (Приход / Расход)
Количество (для приходов +, для расходов -)

+ дополнительная таблица текущих остатков

Приход - транзакция Приход на склад хранения
Перемещение в производство делается двумя транзакциями - списываем со склада хранения и приходуем на склад производства
Расход - транзакция Расход со склада производства
5 июн 17, 17:49    [20541154]     Ответить | Цитировать Сообщить модератору
 Re: Помогите довести до ума модель данных склада  [new]
mkr
Member

Откуда: Беларусь, Брест
Сообщений: 99
Dimitry Sibiryakov,
конечно же логически)
5 июн 17, 17:54    [20541166]     Ответить | Цитировать Сообщить модератору
 Re: Помогите довести до ума модель данных склада  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 43632

mkr
конечно же логически)

А потом идёт инвентаризация и спрашивают кладовщика "а где у вас вот этот вот рулон?", а
ему и сказать нечего.
Не выпендривайся, делай как Кот говорит.

Posted via ActualForum NNTP Server 1.5

5 июн 17, 18:16    [20541205]     Ответить | Цитировать Сообщить модератору
 Re: Помогите довести до ума модель данных склада  [new]
mkr
Member

Откуда: Беларусь, Брест
Сообщений: 99
интересное решение от bideveloper


по предложению Кот Матроскин, как Я понял, расширить использование WP_ROLLS_OUT (что в этой таблице, значит в производстве, останется только остатки посчитать)
8 июн 17, 10:23    [20549102]     Ответить | Цитировать Сообщить модератору
 Re: Помогите довести до ума модель данных склада  [new]
LSV
Member

Откуда: Киев
Сообщений: 29966
mkr
интересное решение от bideveloper
Вообще-то это классика любого складского учета.
В том же Навижн вообще нет физического понятия/поля "остаток". Есть "сумма движений на дату". Считает на лету.
8 июн 17, 10:41    [20549190]     Ответить | Цитировать Сообщить модератору
 Re: Помогите довести до ума модель данных склада  [new]
mkr
Member

Откуда: Беларусь, Брест
Сообщений: 99
bideveloper
например, best practices на основе Microsoft Dynamics (упрощенно):

Есть таблица складских транзакций inventtrans c полями
Дата транзакции (дата прихода расхода)
Номенклатура (бумага)
Аналитика (склад, номер рулона)
Тип транзакции (Приход / Расход)
Количество (для приходов +, для расходов -)

+ дополнительная таблица текущих остатков

внедрил, крутится!

появилась ещё парочка вопросов - так ли необходим Тип транзакции (можно же определять из прихода: >0 приход, <0 расход)?

как удобнее считать остатки?
текущие остатки можно делать через триггеры
остатки на дату - полный расчёт или через те же триггеры делать хотя бы месячные снапшоты + движение по месяцу до нужной даты?
7 июл 17, 11:19    [20622161]     Ответить | Цитировать Сообщить модератору
 Re: Помогите довести до ума модель данных склада  [new]
Cane Cat Fisher
Member

Откуда:
Сообщений: 1418
mkr
внедрил, крутится!

появилась ещё парочка вопросов - так ли необходим Тип транзакции (можно же определять из прихода: >0 приход, <0 расход)?

как удобнее считать остатки?
текущие остатки можно делать через триггеры
остатки на дату - полный расчёт или через те же триггеры делать хотя бы месячные снапшоты + движение по месяцу до нужной даты?


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

Хранить ли остатки на концы месяцев? С одной стороны, можно и без них, если база небольшая и расчет на лету проходит достаточно быстро. С другой стороны, хранить их все же удобно. Ведь остатки на произвольную дату нужны редко. Чаще либо текущие, либо помесячные, например для аналитики за год. Тут-то они и пригодятся.
7 июл 17, 11:52    [20622338]     Ответить | Цитировать Сообщить модератору
 Re: Помогите довести до ума модель данных склада  [new]
LSV
Member

Откуда: Киев
Сообщений: 29966
автор
так ли необходим Тип транзакции
Жизненно необходим.
Расход это : продажа, списание, инвентаризация, возврат поставщику, вн.перемещение и пр.
Приход это : покупка, инвентаризация, возврат от покупателя, вн.перемещение и пр.
7 июл 17, 12:02    [20622397]     Ответить | Цитировать Сообщить модератору
 Re: Помогите довести до ума модель данных склада  [new]
s_ustinov
Member

Откуда: Lugano, CH
Сообщений: 1750
Cane Cat Fisher
Хранить ли остатки на концы месяцев? С одной стороны, можно и без них, если база небольшая и расчет на лету проходит достаточно быстро. С другой стороны, хранить их все же удобно. Ведь остатки на произвольную дату нужны редко. Чаще либо текущие, либо помесячные, например для аналитики за год. Тут-то они и пригодятся.

За такие советы надо брать введение Дейта и по голове несколько раз, пока смысл слова "нормализация" не пробьется сквозь кость. 😀

Хранить остатки НЕ НУЖНО. Для этого есть индексы.
8 июл 17, 11:25    [20625465]     Ответить | Цитировать Сообщить модератору
 Re: Помогите довести до ума модель данных склада  [new]
LSV
Member

Откуда: Киев
Сообщений: 29966
s_ustinov
Хранить остатки НЕ НУЖНО. Для этого есть индексы.
Ога. Смотря сколько остатков. Если это база сети маркетов (штук хотя бы на сто), то никакие индексы не помогут. Что-то таки придется хранить... :)
10 июл 17, 11:29    [20628457]     Ответить | Цитировать Сообщить модератору
 Re: Помогите довести до ума модель данных склада  [new]
s_ustinov
Member

Откуда: Lugano, CH
Сообщений: 1750
LSV
s_ustinov
Хранить остатки НЕ НУЖНО. Для этого есть индексы.
Ога. Смотря сколько остатков. Если это база сети маркетов (штук хотя бы на сто), то никакие индексы не помогут. Что-то таки придется хранить... :)

Давайте на конкретных примерах.

Предположим, есть таблица товародвижений:
CREATE TABLE [dbo].[Item Ledger Entry](
	[Entry No_] [int] NOT NULL,
	[Item No_] [nvarchar](20) NOT NULL,
	[Posting Date] [datetime] NOT NULL,
	[Entry Type] [int] NOT NULL,
	[Source No_] [nvarchar](20) NOT NULL,
	[Document No_] [nvarchar](20) NOT NULL,
	[Description] [nvarchar](50) NOT NULL,
	[Location Code] [nvarchar](10) NOT NULL,
	[Quantity] [decimal](38, 20) NOT NULL,
 CONSTRAINT [Item Ledger Entry$0] PRIMARY KEY CLUSTERED 
(
	[Entry No_] ASC
)) ON [PRIMARY]
) ON [PRIMARY]


Делаем представление с остатками:
CREATE VIEW [Analysis].[Stocks Remaining]
WITH SCHEMABINDING
AS
SELECT 
	   [Item No_]
	  ,[Location Code]
	  ,COUNT_BIG(*) as [Count_Big]
          ,sum([Quantity]) as [Remaining Quantity]
  FROM [dbo].[Item Ledger Entry]
  group by
	   [Item No_]
	  ,[Location Code]


Смотрим остатки:
SELECT [Item No_]
      ,[Location Code]
      ,[Remaining Quantity]
  FROM [Analysis].[Stocks Remaining]


Сперва смотрим без индекса, а потом создаем индекс
CREATE UNIQUE CLUSTERED INDEX [ClusteredIndex] ON [Analysis].[Stocks Remaining]
(
	[Item No_] ASC,
	[Location Code] ASC
) ON [PRIMARY]

и делаем тот же запрос с индексом.

Результат на картинке.

Стоимость запроса без индекса - 135, стоимость запроса с индексом - 0,016. В восемь с половиной тысяч раз лучше - на маленьких данных (2,2 миллиона строк), если данных больше - разница будет еще существеннее.

А теперь, внимание, вопрос - какой альтернативный подход даст лучший результат?

К сообщению приложен файл. Размер - 45Kb
10 июл 17, 13:14    [20628991]     Ответить | Цитировать Сообщить модератору
 Re: Помогите довести до ума модель данных склада  [new]
Кот Матроскин
Member

Откуда: Москва
Сообщений: 7569
s_ustinov
А теперь, внимание, вопрос - какой альтернативный подход даст лучший результат?

Подход, при котором оный пересчет остатков происходит не в онлайне, грузя OLTP, а в специально выбранное время.
10 июл 17, 13:24    [20629058]     Ответить | Цитировать Сообщить модератору
 Re: Помогите довести до ума модель данных склада  [new]
s_ustinov
Member

Откуда: Lugano, CH
Сообщений: 1750
Кот Матроскин
s_ustinov
А теперь, внимание, вопрос - какой альтернативный подход даст лучший результат?

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

Если мы говорим о "модель данных склада", то остатки должны быть актуальны в любой момент времени - они используются в бизнес логике.
Если же мы говорим о системе отчетности, то это правильнее делать в ОТДЕЛЬНОЙ базе.
10 июл 17, 13:30    [20629104]     Ответить | Цитировать Сообщить модератору
 Re: Помогите довести до ума модель данных склада  [new]
Кот Матроскин
Member

Откуда: Москва
Сообщений: 7569
s_ustinov
Кот Матроскин
пропущено...

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

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

Остатки должны быть актуальны, но они не обязаны лежать в окончательном виде в базе - вполне могут получаться запросом "остаток на опорную дату + оборот с тех пор".
А остатки на опорные даты - могут рассчитываться тогда, когда это удобно.
10 июл 17, 14:16    [20629395]     Ответить | Цитировать Сообщить модератору
 Re: Помогите довести до ума модель данных склада  [new]
s_ustinov
Member

Откуда: Lugano, CH
Сообщений: 1750
Кот Матроскин
s_ustinov
пропущено...

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

Остатки должны быть актуальны, но они не обязаны лежать в окончательном виде в базе - вполне могут получаться запросом "остаток на опорную дату + оборот с тех пор".
А остатки на опорные даты - могут рассчитываться тогда, когда это удобно.

Во первых, нарушается нормализация. Если по каким либо причинам остатки на опорную дату рассчитаются с ошибками, то и текущие остатки будут считаться с ошибками, хотя в таблице товародвижений ошибок нет.
Во вторых, усложняется код. Написать запрос к одной вьюшке существенно проще, чем запрос "остаток на опорную дату + оборот с тех пор" - повышаются риски ошибок в коде.
И, в третьих (самое главное), в большинстве случаев вариант с хранением остатков на опорную дату будет в целом работать медленнее, чем индексированное представление. При записи в таблицу в любом случае считается и пишется несколько индексов, и добавление еще одного индекса сильно ситуацию не изменит. Обычно количество операций чтения в несколько раз превышает количество операций записи, а так как чтение из одного индекса существенно быстрее, чем чтение из двух таблиц + группировка + джоин, то общий эффект от хранения остатков будет отрицательным (по сравнению с индексированным представлением).
10 июл 17, 15:40    [20629946]     Ответить | Цитировать Сообщить модератору
 Re: Помогите довести до ума модель данных склада  [new]
bideveloper
Member

Откуда:
Сообщений: 105
mkr
остатки на дату - полный расчёт или через те же триггеры делать хотя бы месячные снапшоты + движение по месяцу до нужной даты?


остатки на дату 2 варианта:
1. Которые используются в бизнес-логике, в Аксапте считается, что они недалеко от текущей даты. Поэтому в классах расчета используется схема: остатки на текущую дату - движение от прошлой даты до текущей, для получения остатков на прошлую дату.
2. для аналитической отчетности используется OLAP, который легко считает остатки на любую дату по таблице транзакций.
10 июл 17, 16:09    [20630075]     Ответить | Цитировать Сообщить модератору
 Re: Помогите довести до ума модель данных склада  [new]
Кот Матроскин
Member

Откуда: Москва
Сообщений: 7569
s_ustinov
И, в третьих (самое главное), в большинстве случаев вариант с хранением остатков на опорную дату будет в целом работать медленнее, чем индексированное представление. При записи в таблицу в любом случае считается и пишется несколько индексов, и добавление еще одного индекса сильно ситуацию не изменит. Обычно количество операций чтения в несколько раз превышает количество операций записи, а так как чтение из одного индекса существенно быстрее, чем чтение из двух таблиц + группировка + джоин, то общий эффект от хранения остатков будет отрицательным (по сравнению с индексированным представлением).

WTF "в целом"?
Вы складываете мухи с котлетами - мало того что производительность разных операций, но даже разных типов операций (чтение и запись).
К разным системам бывают разные требования - бывает "количество операций чтения [остатков] в несколько раз превышает количество операций записи", а бывает, что узкое место - именно и конкретно запись, а остатки можно спокойно посчитать когда-нибудь потом
в нерабочее время.
10 июл 17, 16:14    [20630091]     Ответить | Цитировать Сообщить модератору
 Re: Помогите довести до ума модель данных склада  [new]
s_ustinov
Member

Откуда: Lugano, CH
Сообщений: 1750
Кот Матроскин
s_ustinov
И, в третьих (самое главное), в большинстве случаев вариант с хранением остатков на опорную дату будет в целом работать медленнее, чем индексированное представление. При записи в таблицу в любом случае считается и пишется несколько индексов, и добавление еще одного индекса сильно ситуацию не изменит. Обычно количество операций чтения в несколько раз превышает количество операций записи, а так как чтение из одного индекса существенно быстрее, чем чтение из двух таблиц + группировка + джоин, то общий эффект от хранения остатков будет отрицательным (по сравнению с индексированным представлением).

WTF "в целом"?
Вы складываете мухи с котлетами - мало того что производительность разных операций, но даже разных типов операций (чтение и запись).
К разным системам бывают разные требования - бывает "количество операций чтения [остатков] в несколько раз превышает количество операций записи", а бывает, что узкое место - именно и конкретно запись, а остатки можно спокойно посчитать когда-нибудь потом в нерабочее время.

В тех системах, с которыми я работал, при записи операций товародвижений происходит также чтение остатков - чтобы не отгрузить больше, чем есть в наличии. То есть при записи выполняется и чтение. И сравнивать варианты нужно в комплексе:
Вариант 1 - запись в таблицу, по которой есть индексированное представление + чтение из индекса
Вариант 2 - запись в таблицу без индексированного представления + чтение из таблицы товародвижений, таблицы остатков, группировка и джоин

Я очень сомневаюсь, что второй вариант вообще может быть существенно быстрее первого. И еще менее вероятной выглядит ситуация, что вариант 2 может быть настолько быстрее варианта 1, чтобы имело смысл городить дополнительные процедуры пересчета остатков, писать более сложный код получения остатков и следить, чтобы вся эта конструкция не поломалась.
Заметьте, время расчета остатков в таблице остатков (в нерабочее время) в этом сравнении вообще не учитываем. Также не учитываем соотношение количества транзакций чтения остатков к количеству транзакций записи товародвижений.

Разумеется, можно придумать условный пример, при котором хранение остатков на дату в отдельной таблице имеет смысл. Но давайте обсуждать примеры из реальной жизни OLTP систем.
10 июл 17, 17:09    [20630308]     Ответить | Цитировать Сообщить модератору
 Re: Помогите довести до ума модель данных склада  [new]
Cane Cat Fisher
Member

Откуда:
Сообщений: 1418
s_ustinov
Во первых, нарушается нормализация


Укажите, какие нормальные формы нарушаются при хранении остатков?

s_ustinov
Если по каким либо причинам остатки на опорную дату рассчитаются с ошибками


А если запрос вычисления остатков на лету отработает с ошибкой? "По каким-либо причинам".

s_ustinov
Во вторых, усложняется код. Написать запрос к одной вьюшке существенно проще, чем запрос "остаток на опорную дату + оборот с тех пор" - повышаются риски ошибок в коде.


А почему вы сравниваете с вариантом "остаток на опорную дату + оборот с тех пор"? Если нужны текущие остатки, так и храните текущие. И получать их будет гораздо проще и быстрее, чем "Написать запрос к одной вьюшке".
17 июл 17, 10:21    [20649371]     Ответить | Цитировать Сообщить модератору
 Re: Помогите довести до ума модель данных склада  [new]
s_ustinov
Member

Откуда: Lugano, CH
Сообщений: 1750
Cane Cat Fisher
s_ustinov
Во первых, нарушается нормализация


Укажите, какие нормальные формы нарушаются при хранении остатков?

Не помню Дублирование данных - это ВСЕГДА нарушение нормализации, так как неключевой столбец (количество) зависит от записей в других таблицах.
Cane Cat Fisher
s_ustinov
Если по каким либо причинам остатки на опорную дату рассчитаются с ошибками


А если запрос вычисления остатков на лету отработает с ошибкой? "По каким-либо причинам".

Значит у нас ОЧЕНЬ серьезные проблемы с СУБД. Не с базой, а именно СУБД. Так как индексы считает именно СУБД.

Cane Cat Fisher
s_ustinov
Во вторых, усложняется код. Написать запрос к одной вьюшке существенно проще, чем запрос "остаток на опорную дату + оборот с тех пор" - повышаются риски ошибок в коде.


А почему вы сравниваете с вариантом "остаток на опорную дату + оборот с тех пор"? Если нужны текущие остатки, так и храните текущие. И получать их будет гораздо проще и быстрее, чем "Написать запрос к одной вьюшке".

А можно продемонстрировать на конкретном селекте "получать их будет гораздо проще и быстрее, чем "Написать запрос к одной вьюшке""? Чтобы ваш селект был проще того, который я приводил в качестве примера.
SELECT [Item No_]
      ,[Location Code]
      ,[Remaining Quantity]
  FROM [Analysis].[Stocks Remaining]


А именно такой подход рассматриваю вот по этому:
Кот Матроскин
s_ustinov
пропущено...

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

Остатки должны быть актуальны, но они не обязаны лежать в окончательном виде в базе - вполне могут получаться запросом "остаток на опорную дату + оборот с тех пор".
А остатки на опорные даты - могут рассчитываться тогда, когда это удобно.
17 июл 17, 12:07    [20649772]     Ответить | Цитировать Сообщить модератору
 Re: Помогите довести до ума модель данных склада  [new]
Cane Cat Fisher
Member

Откуда:
Сообщений: 1418
s_ustinov
Cane Cat Fisher
пропущено...

Укажите, какие нормальные формы нарушаются при хранении остатков?

Не помню Дублирование данных - это ВСЕГДА нарушение нормализации, так как неключевой столбец (количество) зависит от записей в других таблицах.


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

И почитайте что-нибудь более практическое, чем это святое писание полувековой давности. Тогда поймете, что нормализация - не самоцель, а средство для избежания аномалий обновления. И денормализация - не преступление, а средство повышения производительности в узких местах. И дискуссия станет более предметной.
17 июл 17, 18:25    [20651563]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Проектирование БД Ответить