| 48 | | Далее. Мне в предложенной схеме не нравится, что часть состояний ("создан", "скомплектован", "проверен" и "прошел ОТК") формируется автоматически (то есть зависит только от состояния составляющих заказ изделий), а часть (точнее, одно - "отгружен") - присваиваются пользователями. Зачем хранить в таблице значение, которое является агрегацией состояний составляющих заказ изделий? ИМХО лучше хранить в заказе только поле-флаг "отгружен", а остальные состояния вычислять каждый раз по мере необходимости - это позволит избежать потенциальных неконсистентных состояний, когда записанное в таблице состояние не соответствует состояниям составляющих заказ изделий (например в результате бага)... |
| 49 | | |
| 50 | | Например если состояния изделий кодируются как 0 (не проверено), 1 (проверено, не прошло ОТК) и 2 (прошло ОТК), то состояние всего заказа в целом легко получается простым MIN(itemState)... |
| | 48 | Далее. Мне в предложенной схеме не нравится, что часть состояний ("создан", "скомплектован", "проверен" и "прошел ОТК") формируется автоматически (то есть зависит только от состояния составляющих заказ изделий), а часть (точнее, одно - "отгружен") - присваиваются пользователями. Зачем хранить в таблице значение, которое является агрегацией состояний составляющих заказ изделий? ИМХО лучше хранить в таблице `orders` только поле-флаг "отгружен", а остальные состояния вычислять каждый раз по мере необходимости - это позволит избежать потенциальных неконсистентных состояний, когда записанное в таблице состояние не соответствует состояниям составляющих заказ изделий (например в результате бага). Например если состояния изделий кодировать как 0 (не проверено), 1 (проверено, не прошло ОТК) и 2 (прошло ОТК), то состояние всего заказа в целом легко получается простым MIN(itemState)... |
![[MC-04 logo]](/mc-04/chrome/site/logo.png){kind=logo}
