ReSQL.ru
     
powered by simpleCommunicator - 2.0.46     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Помогите довести до ума модель данных склада
25 сообщений из 41, страница 1 из 2
  1  все
Помогите довести до ума модель данных склада
    #39465960
mkr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mkr
Участник
Делал когда-то простенькую модель склада

Приход сырья (бумага):
Код: plsql
1.
2.
3.
4.
5.
6.
7.
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)
);


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

склад сбрасывает рулоны на расход добавляя рулон в "промежуточную" табличку
Код: plsql
1.
2.
3.
4.
5.
6.
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)
Код: plsql
1.
2.
3.
4.
5.
6.
7.
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 (первая смена в котором использовался рулон)

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



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

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

p.s. к этой теме вернулся из-за того, что нужно выводить остатков бумаги на производстве на каждый день, что выльется в огромную кучу условий
...
Рейтинг: 0 / 0
05.06.2017, 15:34
| Ответить | Цитировать | Написать  
Помогите довести до ума модель данных склада
    #39466095
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кот Матроскин
Участник
Если смотреть на Вашу схему -
не очень понятно, зачем Вам условие NOT IN WP_ROLLS_SHIFT.
Почему бы сразу не выкидывать рулон из WP_ROLLS_OUT, если он начал расходоваться?
Когда Вам нужна выборка из WP_ROLLS_OUT включая те, которые есть в WP_ROLLS_SHIFT?

best practices безусловно есть, и они мало похожи на Ваши :)
Я бы советовал для начала постараться свести бизнес-процессы к двум операциям "приход" и "списание", не пытаясь создавать какие-то дополнительные сущности.
Скажем, бизнес-процесс "сбрасывает рулоны на расход" я бы попробовал описать как "списание с основного склада" + "приход на виртуальный склад-производство".
"используется в производстве" = "списание с виртуального склада-производства".
Если это получится - можно задуматься о том, как хранить остатки так, чтобы эти операции
эффективно создавались и учитывались
Если некий бизнес-процесс совсем, ну совсем никак не ложится на эти 2 операции- ну тогда надо уже задумываться "а не завести ли новую сущность".
...
Рейтинг: 0 / 0
05.06.2017, 17:02
| Ответить | Цитировать | Написать  
Помогите довести до ума модель данных склада
    #39466123
mkr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mkr
Участник
Кот Матроскин,
авторзачем Вам условие NOT IN WP_ROLLS_SHIFT.
пока рулон не использовался - он на складе

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

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

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

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

"используется в производстве" = "списание с виртуального склада-производства" - если рулон использован до конца - его списываем сразу, а вот если на нём остался остаток - вот тогда он болтается... при том, что его остаток висит на самом рулоне (для того, чтобы вывести остатки на определённую дату - получается ни то ни сё)
...
Рейтинг: 0 / 0
05.06.2017, 17:34
| Ответить | Цитировать | Написать  
Помогите довести до ума модель данных склада
    #39466130
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
mkrпока рулон не использовался - он на складе

Физически? Не верю. Что это за производство/станок, который способен жрать бумагу прямо из
рулона, лежащего на складе?
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
05.06.2017, 17:49
| Ответить | Цитировать | Написать  
Помогите довести до ума модель данных склада
    #39466131
bideveloper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
bideveloper
Участник
mkr,
например, best practices на основе Microsoft Dynamics (упрощенно):

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

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

Приход - транзакция Приход на склад хранения
Перемещение в производство делается двумя транзакциями - списываем со склада хранения и приходуем на склад производства
Расход - транзакция Расход со склада производства
...
Рейтинг: 0 / 0
05.06.2017, 17:49
| Ответить | Цитировать | Написать  
Помогите довести до ума модель данных склада
    #39466137
mkr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mkr
Участник
Dimitry Sibiryakov,
конечно же логически)
...
Рейтинг: 0 / 0
05.06.2017, 17:54
| Ответить | Цитировать | Написать  
Помогите довести до ума модель данных склада
    #39466149
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
mkrконечно же логически)

А потом идёт инвентаризация и спрашивают кладовщика "а где у вас вот этот вот рулон?", а
ему и сказать нечего.
Не выпендривайся, делай как Кот говорит.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
05.06.2017, 18:16
| Ответить | Цитировать | Написать  
Помогите довести до ума модель данных склада
    #39468362
mkr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mkr
Участник
интересное решение от bideveloper


по предложению Кот Матроскин , как Я понял, расширить использование WP_ROLLS_OUT (что в этой таблице, значит в производстве, останется только остатки посчитать)
...
Рейтинг: 0 / 0
08.06.2017, 10:23
| Ответить | Цитировать | Написать  
Помогите довести до ума модель данных склада
    #39468382
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LSV
Участник
mkrинтересное решение от bideveloper Вообще-то это классика любого складского учета.
В том же Навижн вообще нет физического понятия/поля "остаток". Есть "сумма движений на дату". Считает на лету.
...
Рейтинг: 0 / 0
08.06.2017, 10:41
| Ответить | Цитировать | Написать  
Помогите довести до ума модель данных склада
    #39484347
mkr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mkr
Участник
bideveloperнапример, best practices на основе Microsoft Dynamics (упрощенно):

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

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

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

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

как удобнее считать остатки?
текущие остатки можно делать через триггеры
остатки на дату - полный расчёт или через те же триггеры делать хотя бы месячные снапшоты + движение по месяцу до нужной даты?
...
Рейтинг: 0 / 0
07.07.2017, 11:19
| Ответить | Цитировать | Написать  
Помогите довести до ума модель данных склада
    #39484380
Cane Cat Fisher
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Cane Cat Fisher
Участник
mkrвнедрил, крутится!

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

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

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

Хранить ли остатки на концы месяцев? С одной стороны, можно и без них, если база небольшая и расчет на лету проходит достаточно быстро. С другой стороны, хранить их все же удобно. Ведь остатки на произвольную дату нужны редко. Чаще либо текущие, либо помесячные, например для аналитики за год. Тут-то они и пригодятся.
...
Рейтинг: 0 / 0
07.07.2017, 11:52
| Ответить | Цитировать | Написать  
Помогите довести до ума модель данных склада
    #39484395
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LSV
Участник
автортак ли необходим Тип транзакцииЖизненно необходим.
Расход это : продажа, списание, инвентаризация, возврат поставщику, вн.перемещение и пр.
Приход это : покупка, инвентаризация, возврат от покупателя, вн.перемещение и пр.
...
Рейтинг: 0 / 0
07.07.2017, 12:02
| Ответить | Цитировать | Написать  
Помогите довести до ума модель данных склада
    #39485027
s_ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
s_ustinov
Участник
Cane Cat FisherХранить ли остатки на концы месяцев? С одной стороны, можно и без них, если база небольшая и расчет на лету проходит достаточно быстро. С другой стороны, хранить их все же удобно. Ведь остатки на произвольную дату нужны редко. Чаще либо текущие, либо помесячные, например для аналитики за год. Тут-то они и пригодятся.
За такие советы надо брать введение Дейта и по голове несколько раз, пока смысл слова "нормализация" не пробьется сквозь кость. 😀

Хранить остатки НЕ НУЖНО. Для этого есть индексы.
...
Рейтинг: 0 / 0
08.07.2017, 11:25
| Ответить | Цитировать | Написать  
Помогите довести до ума модель данных склада
    #39485597
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LSV
Участник
s_ustinovХранить остатки НЕ НУЖНО. Для этого есть индексы.Ога. Смотря сколько остатков. Если это база сети маркетов (штук хотя бы на сто), то никакие индексы не помогут. Что-то таки придется хранить... :)
...
Рейтинг: 0 / 0
10.07.2017, 11:29
| Ответить | Цитировать | Написать  
Помогите довести до ума модель данных склада
    #39485713
s_ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
s_ustinov
Участник
LSVs_ustinovХранить остатки НЕ НУЖНО. Для этого есть индексы.Ога. Смотря сколько остатков. Если это база сети маркетов (штук хотя бы на сто), то никакие индексы не помогут. Что-то таки придется хранить... :)
Давайте на конкретных примерах.

Предположим, есть таблица товародвижений:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
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]



Делаем представление с остатками:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
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]



Смотрим остатки:
Код: sql
1.
2.
3.
4.
SELECT [Item No_]
      ,[Location Code]
      ,[Remaining Quantity]
  FROM [Analysis].[Stocks Remaining]



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


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

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

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

А теперь, внимание, вопрос - какой альтернативный подход даст лучший результат?
...
Рейтинг: 0 / 0
10.07.2017, 13:14
| Ответить | Цитировать | Написать  
Помогите довести до ума модель данных склада
    #39485724
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кот Матроскин
Участник
s_ustinovА теперь, внимание, вопрос - какой альтернативный подход даст лучший результат?
Подход, при котором оный пересчет остатков происходит не в онлайне, грузя OLTP, а в специально выбранное время.
...
Рейтинг: 0 / 0
10.07.2017, 13:24
| Ответить | Цитировать | Написать  
Помогите довести до ума модель данных склада
    #39485734
s_ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
s_ustinov
Участник
Кот Матроскинs_ustinovА теперь, внимание, вопрос - какой альтернативный подход даст лучший результат?
Подход, при котором оный пересчет остатков происходит не в онлайне, грузя OLTP, а в специально выбранное время.
Если мы говорим о "модель данных склада", то остатки должны быть актуальны в любой момент времени - они используются в бизнес логике.
Если же мы говорим о системе отчетности, то это правильнее делать в ОТДЕЛЬНОЙ базе.
...
Рейтинг: 0 / 0
10.07.2017, 13:30
| Ответить | Цитировать | Написать  
Помогите довести до ума модель данных склада
    #39485783
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кот Матроскин
Участник
s_ustinovКот Матроскинпропущено...

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

Остатки должны быть актуальны, но они не обязаны лежать в окончательном виде в базе - вполне могут получаться запросом "остаток на опорную дату + оборот с тех пор".
А остатки на опорные даты - могут рассчитываться тогда, когда это удобно.
...
Рейтинг: 0 / 0
10.07.2017, 14:16
| Ответить | Цитировать | Написать  
Помогите довести до ума модель данных склада
    #39485831
s_ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
s_ustinov
Участник
Кот Матроскинs_ustinovпропущено...

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

Остатки должны быть актуальны, но они не обязаны лежать в окончательном виде в базе - вполне могут получаться запросом "остаток на опорную дату + оборот с тех пор".
А остатки на опорные даты - могут рассчитываться тогда, когда это удобно.
Во первых, нарушается нормализация. Если по каким либо причинам остатки на опорную дату рассчитаются с ошибками, то и текущие остатки будут считаться с ошибками, хотя в таблице товародвижений ошибок нет.
Во вторых, усложняется код. Написать запрос к одной вьюшке существенно проще, чем запрос "остаток на опорную дату + оборот с тех пор" - повышаются риски ошибок в коде.
И, в третьих (самое главное), в большинстве случаев вариант с хранением остатков на опорную дату будет в целом работать медленнее, чем индексированное представление . При записи в таблицу в любом случае считается и пишется несколько индексов, и добавление еще одного индекса сильно ситуацию не изменит. Обычно количество операций чтения в несколько раз превышает количество операций записи, а так как чтение из одного индекса существенно быстрее, чем чтение из двух таблиц + группировка + джоин, то общий эффект от хранения остатков будет отрицательным (по сравнению с индексированным представлением).
...
Рейтинг: 0 / 0
10.07.2017, 15:40
| Ответить | Цитировать | Написать  
Помогите довести до ума модель данных склада
    #39485868
bideveloper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
bideveloper
Участник
mkrостатки на дату - полный расчёт или через те же триггеры делать хотя бы месячные снапшоты + движение по месяцу до нужной даты?

остатки на дату 2 варианта:
1. Которые используются в бизнес-логике, в Аксапте считается, что они недалеко от текущей даты. Поэтому в классах расчета используется схема: остатки на текущую дату - движение от прошлой даты до текущей, для получения остатков на прошлую дату.
2. для аналитической отчетности используется OLAP, который легко считает остатки на любую дату по таблице транзакций.
...
Рейтинг: 0 / 0
10.07.2017, 16:09
| Ответить | Цитировать | Написать  
Помогите довести до ума модель данных склада
    #39485873
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кот Матроскин
Участник
s_ustinovИ, в третьих (самое главное), в большинстве случаев вариант с хранением остатков на опорную дату будет в целом работать медленнее, чем индексированное представление . При записи в таблицу в любом случае считается и пишется несколько индексов, и добавление еще одного индекса сильно ситуацию не изменит. Обычно количество операций чтения в несколько раз превышает количество операций записи, а так как чтение из одного индекса существенно быстрее, чем чтение из двух таблиц + группировка + джоин, то общий эффект от хранения остатков будет отрицательным (по сравнению с индексированным представлением).
WTF "в целом"?
Вы складываете мухи с котлетами - мало того что производительность разных операций, но даже разных типов операций (чтение и запись).
К разным системам бывают разные требования - бывает "количество операций чтения [остатков] в несколько раз превышает количество операций записи", а бывает, что узкое место - именно и конкретно запись, а остатки можно спокойно посчитать когда-нибудь потом
в нерабочее время.
...
Рейтинг: 0 / 0
10.07.2017, 16:14
| Ответить | Цитировать | Написать  
Помогите довести до ума модель данных склада
    #39485925
s_ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
s_ustinov
Участник
Кот Матроскинs_ustinovИ, в третьих (самое главное), в большинстве случаев вариант с хранением остатков на опорную дату будет в целом работать медленнее, чем индексированное представление . При записи в таблицу в любом случае считается и пишется несколько индексов, и добавление еще одного индекса сильно ситуацию не изменит. Обычно количество операций чтения в несколько раз превышает количество операций записи, а так как чтение из одного индекса существенно быстрее, чем чтение из двух таблиц + группировка + джоин, то общий эффект от хранения остатков будет отрицательным (по сравнению с индексированным представлением).
WTF "в целом"?
Вы складываете мухи с котлетами - мало того что производительность разных операций, но даже разных типов операций (чтение и запись).
К разным системам бывают разные требования - бывает "количество операций чтения [остатков] в несколько раз превышает количество операций записи", а бывает, что узкое место - именно и конкретно запись, а остатки можно спокойно посчитать когда-нибудь потом в нерабочее время.
В тех системах, с которыми я работал, при записи операций товародвижений происходит также чтение остатков - чтобы не отгрузить больше, чем есть в наличии. То есть при записи выполняется и чтение. И сравнивать варианты нужно в комплексе:
Вариант 1 - запись в таблицу, по которой есть индексированное представление + чтение из индекса
Вариант 2 - запись в таблицу без индексированного представления + чтение из таблицы товародвижений, таблицы остатков, группировка и джоин

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

Разумеется, можно придумать условный пример, при котором хранение остатков на дату в отдельной таблице имеет смысл. Но давайте обсуждать примеры из реальной жизни OLTP систем.
...
Рейтинг: 0 / 0
10.07.2017, 17:09
| Ответить | Цитировать | Написать  
Помогите довести до ума модель данных склада
    #39489981
Cane Cat Fisher
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Cane Cat Fisher
Участник
s_ustinovВо первых, нарушается нормализация

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

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

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

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

А почему вы сравниваете с вариантом "остаток на опорную дату + оборот с тех пор"? Если нужны текущие остатки, так и храните текущие. И получать их будет гораздо проще и быстрее, чем "Написать запрос к одной вьюшке".
...
Рейтинг: 0 / 0
17.07.2017, 10:21
| Ответить | Цитировать | Написать  
Помогите довести до ума модель данных склада
    #39490075
s_ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
s_ustinov
Участник
Cane Cat Fishers_ustinovВо первых, нарушается нормализация

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

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

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

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



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

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

Остатки должны быть актуальны, но они не обязаны лежать в окончательном виде в базе - вполне могут получаться запросом "остаток на опорную дату + оборот с тех пор".
А остатки на опорные даты - могут рассчитываться тогда, когда это удобно.
...
Рейтинг: 0 / 0
17.07.2017, 12:07
| Ответить | Цитировать | Написать  
Помогите довести до ума модель данных склада
    #39490342
Cane Cat Fisher
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Cane Cat Fisher
Участник
s_ustinovCane Cat Fisherпропущено...

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

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

И почитайте что-нибудь более практическое, чем это святое писание полувековой давности. Тогда поймете, что нормализация - не самоцель, а средство для избежания аномалий обновления. И денормализация - не преступление, а средство повышения производительности в узких местах. И дискуссия станет более предметной.
...
Рейтинг: 0 / 0
17.07.2017, 18:25
| Ответить | Цитировать | Написать  
25 сообщений из 41, страница 1 из 2
  1  все
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Помогите довести до ума модель данных склада
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru             Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=32&fpage=3&tid=1539858]:
 0ms
get settings:
 9ms
get forum list:
 14ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 32ms
get topic data:
 12ms
get forum data:
 2ms
get page messages:
 68ms
get tp. blocked users:
 3ms
others: 12ms
total:  160ms
созд. / загр.: 160ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]