Работа с заказами

[san]

Интерфейс Заказы.

В таблице необходимо отображать поля - номер заказа / дата создания/ срок исполнения(дата)/ статус/ получатель
Статус: создан, скомплектован, проверен, прошёл ОТК, отгружен.
Создан - устанавливается при создании заказа работником производства со специальным правом "редактирования заказов" через интерфейс "Редактирование заказа".
Скомплектован - устанавливается автоматически через интерфейс "Редактирование заказа" когда ко всем изделиям в заказе добавлены конкретные серийные номера.
Проверен, Прошел ОТК - устанавливается автоматически через интерфейсы Тестирование, ОТК
Отгружен - устанавливается через интерфейс отгрузка

Необходимые фильтры:

• все заказы(фильтры отключены)
• все заказы, кроме отгруженных неделю назад и ранее

Интерфейс Редактирование заказа

• позволяет создать заказ (указывается год/номер заказа)
• позволяет добавить в заказ изделия без серийных номеров указав их имя и задав количество штук
• позволяет заполнить серийные номера для выбранных изделий (с проверкой соответствия имени изделия)

[san]

Комментарий от Дениса:
Выполнение.

Создание таблицы orders:
create table orders (id integer not null UNIQUE,
datetime datetime not null,
deadline date not null,
status enum ('created', 'accept', 'completed', 'verify', 'otk', 'shipped') not null,
recipient varchar (200) not null)
Создание таблицы orders-items:
CREATE TABLE order-items ( order-items - в кавычках, наклонённых влево, иначе при создании будет ошибка
order_id INT(32) NOT NULL,
serial VARCHAR(100),
type VARCHAR(100) NOT NULL,
name VARCHAR(100) NOT NULL,
parent VARCHAR(100),
UNIQUE KEY (order_id,serial),
FOREIGN KEY (order_id) REFERENCES orders (id) ON DELETE CASCADE,
FOREIGN KEY (serial) REFERENCES products (serial) ON DELETE RESTRICT)
mysql> show columns from orders;
+-----------+---------------------------------------------------------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-----------+---------------------------------------------------------------+------+-----+---------+-------+
| id | int | NO | PRI | NULL | |
| datetime | datetime | NO | | NULL | |
| deadline | date | NO | | NULL | |
| status | enum('created','accept','completed','verify','otk','shipped') | NO | | NULL | |
| recipient | varchar(200) | NO | | NULL | |
+-----------+---------------------------------------------------------------+------+-----+---------+-------+

mysql> show columns from order-items;
+----------+--------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+----------+--------------+------+-----+---------+-------+
| order_id | int | NO | MUL | NULL | |
| serial | varchar(100) | YES | MUL | NULL | |
| type | varchar(100) | NO | | NULL | |
| name | varchar(100) | NO | | NULL | |
| parent | varchar(100) | YES | | NULL | |
+----------+--------------+------+-----+---------+-------+

Версия 1.0 интерфейса "Заказы": 40195fb
Права у того, кто создает заказ:"createorder". У того, кто заносит серийные номера: "addserial".
Таблицы order-items и orders необходимо привести к виду, указанному выше.
Не сделано: статус заказа не меняется из других интерфейсов.

[alx]

Replying to san:

CREATE TABLE order-items ( order-items - в кавычках, наклонённых влево, иначе при создании будет ошибка
order_id INT(32) NOT NULL,
serial VARCHAR(100),
type VARCHAR(100) NOT NULL,
name VARCHAR(100) NOT NULL,
parent VARCHAR(100),
UNIQUE KEY (order_id,serial),
FOREIGN KEY (order_id) REFERENCES orders (id) ON DELETE CASCADE,
FOREIGN KEY (serial) REFERENCES products (serial) ON DELETE RESTRICT)

Я обнаружил здесь дублирование информации: поля type и name присутствуют и в таблице order-items, и в таблице products. Так как серийный номер уже однозначно идентифицирует изделие, не лучше ли нормализовать таблицу order-items, удалив из нее столбцы type и name?

Также есть вопрос по поводу столбца parent. Его назначение мне неизвестно, в реальной ДБ он всегда содержит NULL. Если я верно догадался из его названия, что в нем предполагается хранить указание на изделие, в которое входит описываемая строкой позиция (например указание на кассету, в которую установлена заказанная плата), то следовало бы добавить для этого поля FOREIGN KEY для исключения возможности указания несуществующего серийного номера.

[alx]

Replying to alx:

Я обнаружил здесь дублирование информации: поля type и name присутствуют и в таблице order-items, и в таблице products. Так как серийный номер уже однозначно идентифицирует изделие, не лучше ли нормализовать таблицу order-items, удалив из нее столбцы type и name?

Я, кажется, сам понял, в чем тут суть. Когда сотрудник отдела продаж создает заказ, он не может указать никакие серийные номера. Он может указать только наименования и количество изделий. А серийные номера указываются позже, уже на производстве... В таком случае, первое предложение comment:5 снимается.

Непонятен теперь другой момент: каким образом в реальной БД я вижу, что только что созданные заказы (заказы в статусе 'created') уже имеют серийный номера плат (например заказ 2022003)? Каким образом эти номера туда попали, если заказ еще даже не был принят производственным отделом?

[san]

Также есть вопрос по поводу столбца parent. Его назначение мне неизвестно, в реальной ДБ он всегда содержит NULL. Если я верно догадался из его названия, что в нем предполагается хранить указание на изделие, в которое входит описываемая строкой позиция (например указание на кассету, в которую установлена заказанная плата), то следовало бы добавить для этого поля FOREIGN KEY для исключения возможности указания несуществующего серийного номера.

Да, правильно понял. Но пока не понятно кто и когда в реальной жизни будет этот столбец заполнять. С предложением добавить FOREIGN KEY согласен.

Я, кажется, сам понял, в чем тут суть. Когда сотрудник отдела продаж создает заказ, он не может указать никакие серийные номера. Он может указать только наименования и количество изделий. А серийные номера указываются позже, уже на производстве... В таком случае, первое предложение comment:5 снимается.

Суть такая, да. Имя изделия в заказе нужно до тех пор пока не известен его серийный номер(поле тип теперь планируется не использовать в таблицах products и order_items т.к. договорились об уникальности имени изделия и тип всегда можно узнать из list_of_products)

Непонятен теперь другой момент: каким образом в реальной БД я вижу, что только что созданные заказы (заказы в статусе 'created') уже имеют серийный номера плат (например заказ 2022003)? Каким образом эти номера туда попали, если заказ еще даже не был принят производственным отделом?

Исходя из реалий план немного изменился, заказ теперь должен создаваться и наполняться серийными номерами в едином интерфейсе(создают и заполняют сотрудники производства), причём, пока заказ не отгружен, состав заказа может измениться. Статуса "принят" теперь нет.
Замечу что интерфейсом создания и изменения заказа ещё пока не пользуются в реальной базе(онещё не внедрён), сейчас заказы создаются и наполняются по старой схеме через интерфейс ОТК.

[alx]

Replying to san:

После нажатия =>Если не существует платы в базе:
Записать в products => serial, type = тип , name = имя, location = 'work', owner = 'АДС', date = now(), testing = 'notest'???, otk = 'nocheck', mismatch = 'no', repair = 'no', comment = 'no'.
Записать в history => uid (из products), type_write = 'record', worker, date = now(), order_from = 'stock(склад)', whom_order = work(производство), comment = 'product from stock, add in list of 'ship(продукт со склада, добавлен в лист отправки).

Мне кажется, что так делать неправильно...
Откуда у комплектующего заказ сотрудника может взяться плата, которой нет в БД? Если серийного номера нет в БД, то это значит одно из двух:

1. Наиболее вероятное - сотрудник ошибся при вводе. И тогда надо просто выдать сообщение об ошибке.
2. Была нарушена процедура изготовления платы (плата не была принята из монтажа, не была протестирована и т.п.). В этом случае ИМХО следует не прятать этот иннцидент "под ковер", создавая фиктивную запись (а она фиктивная - сотрудник, комплектующий заказ, не получал плату из монтажа, и плата была получена из монтажа не сейчас и т.д.). Мне кажется, в этом случае требуется выдать ошибку, чтобы соответствующие должностные лица провели расследование - выянили, как так получилось, что физически плата есть, а по документам (в БД) - отсутствует, кого надо наказать, где надо скорректировать инструкции чтобы такого больше не происходило и т.п...

[san]

Мне кажется, что так делать неправильно...

Согласен.
Так и не делается, этот тикет устарел :( интерфейс Заказы реализован с большими отличиями от этого задания.
Попробую актуализировать тикет...

[alx]

Replying to san:

Исходя из реалий план немного изменился, заказ теперь должен создаваться и наполняться серийными номерами в едином интерфейсе(создают и заполняют сотрудники производства),

Как сотрудник отдела производства может создать заказ? Откуда он знает, что хочет купить покупатель? Это может знать только зам директора по маркетингу, так как он принимает запросы покупателей...

Статуса "принят" теперь нет.

Вообще-то пока еще есть, просто не записывается в БД (что меня тоже удивило)...

То есть теперь покупатели звонят сразу в ПТО, и принявший звонок сотрудник сразу бежит на склад комплектовать заказ платами? 8-( ) Очень необычно...

[san]

Отдел маркетинга передаёт заказы на производство другим способом, не через базу.
А на производстве создают заказ в базе.

Статуса "принят" теперь нет.

Вообще-то пока еще есть

Я имел в виду что этот статус больше не используется. Из базы ещё не удалил.

[alx]

Replying to san:

Отдел маркетинга передаёт заказы на производство другим способом, не через базу.

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

[san]

Оставим этот вопрос риторическим)

[san]

Актуализировал задание.

[alx]

Replying to san:

Актуализировал задание.

Спасибо. С твоего молчаливого позволения :) еще немного покритикую постановку задачи.

Про сортировку ничего не сказано. Насколько я вижу, сейчас заказы всегда отображаются в порядке, обратном их созданию. Получается, что сотрудник ПТО в первую очередь начинает комплектовать самый новый (свежий) заказ, и в последнюю - самый старый (который поступил раньше)... ИМХО это не то, чего ожидают покупатели - они ожидают, что какой заказ раньше создан, такой и должен раньше пойти в работу. Это было бы более справедливо. Кроме этого, для исполнителя более важным является столбец deadline, так как если заказ создан вчера, а deadline у него - завтра, то работать с таким заказом надо раньше, чем с заказом, созданным два месяца назад, но deadline у которого - через год или вообще отсутствует... Сейчас же deadline при сортировке вообще не учитывается...

Почему такой "небогатый" набор фильтров? Например сотрудника, занимающегося отгрузкой проверенных заказов, интересуют только заказы, имеющие статус "Прошел ОТК". Однако такой возможности не предусмотрено...

Не предусмотрена возможность поиска (фильтрации) по наименованию заказчика - а это ИМХО достаточно частая задача - посмотреть состояние заказов конкретного покупателя (он только что позвонил и спрашивает, в каком состоянии его заказы, номеров которых он, конечно, не помнит, сотрудник производства будет визуально искать нужные заказы среди нескольких тысяч?)...

Набор состояний заказа мне кажется недостаточным. Например, не вижу промежуточного состояния между "прошел ОТК" и "отгружен" (диаграмма упрощенная мне лень перечислять все возможные переходы между состояниями):

Отличие "прошел ОТК" и "отгружается" в том, что в состоянии "отгружается" в состав заказа уже не могут вноситься никакие изменения. Если же состояния "отгружается" нет, то получается, что в состав заказа нельзя вносить изменения в состоянии "прошел ОТК", что не очень удобно, так как в это состояние заказ может попасть автоматически, как только на складе набрали нужные платы...

Далее. Мне в предложенной схеме не нравится, что часть состояний ("создан", "скомплектован", "проверен" и "прошел ОТК") формируется автоматически (то есть зависит только от состояния составляющих заказ изделий), а часть (точнее, одно - "отгружен") - присваиваются пользователями. Зачем хранить в таблице значение, которое является агрегацией состояний составляющих заказ изделий? ИМХО лучше хранить в таблице orders только поле-флаг "отгружен", а остальные состояния вычислять каждый раз по мере необходимости - это позволит избежать потенциальных неконсистентных состояний, когда записанное в таблице состояние не соответствует состояниям составляющих заказ изделий (например в результате бага). Например если состояния изделий кодировать как 0 (не проверено), 1 (проверено, не прошло ОТК) и 2 (прошло ОТК), то состояние всего заказа в целом легко получается простым MIN(itemState)...

И еще, разве манипуляции с заказом (создание, комплектация, отгрузка) не должны сопровождаться записями в историю? В описании ничего не сказано о том, какие именно события должны фиксироваться. А ведь менеджер (или даже покупатель) может захотеть узнать не только текущее состояние заказа, а например, когда заказ переходил из одного состояния в другое...

[alx]

А, кстати, куда предполагается записывать номер накладной отправки заказа?

[alx]

А вот еще вопрос, не освещенный в описании. Предположим, имеется заказ из одной платы в состоянии "скомплектован". Плату, назначенную этому заказу, протестировали, и она оказалась дефектной. В какой состояние должен перейти заказ?

Вроде бы ни в какое - должен остаться в состоянии "скомплектован", так как нет специального состояния для "дефектного" заказа. Но тогда заказ останется в этом состоянии надолго (если не навсегда), так как когда отремонтируют именно эту неисправную плату неизвестно, а комплектация заказа уже выполнена, и по состоянию заказа никак не видно, что он требует перекомплектации (замены дефектной платы на другую)...

Может быть надо предусмотреть еще какое-то "проблемное" состояние заказа?

Похожая ситуация может возникнуть, если плату "завернул" контролер ОТК...

[san]

Про сортировку ничего не сказано
"небогатый" набор фильтров

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

сотрудник ПТО в первую очередь...

Сотрудники ПТО сейчас руководствуются другой системой, которая раздаёт приоритеты.

Далее. Мне в предложенной схеме не нравится, что часть состояний ("создан", "скомплектован", "проверен" и "прошел ОТК") формируется автоматически (то есть зависит только от состояния составляющих заказ изделий), а часть (точнее, одно - "отгружен") - присваиваются пользователями. Зачем хранить в таблице значение, которое является агрегацией состояний составляющих заказ изделий? ИМХО лучше хранить в таблице orders только поле-флаг "отгружен", а остальные состояния вычислять каждый раз по мере необходимости - это позволит избежать потенциальных неконсистентных состояний, когда записанное в таблице состояние не соответствует состояниям составляющих заказ изделий (например в результате бага). Например если состояния изделий кодировать как 0 (не проверено), 1 (проверено, не прошло ОТК) и 2 (прошло ОТК), то состояние всего заказа в целом легко получается простым MIN(itemState)...

Согласен. Обсудили с Денисом, создал #1020

[alx]

Replying to san:

Сотрудники ПТО сейчас руководствуются другой системой, которая раздаёт приоритеты.

В таком случае, каково назначение столбца deadline таблицы заказов?

[san]

В таком случае, каково назначение столбца deadline таблицы заказов?

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

[alx]

Replying to san:

В таком случае, каково назначение столбца deadline таблицы заказов?

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

А, то есть это просто справочная информация, никак не влияющая на бизнес-процессы...

И еще один вопрос у меня возник "на свежую голову": в чем смысл комплектации заказа непроверенными и/или не прошедшими ОТК изделиями?

Если принять, что заказ можно комплектовать только готовыми к продаже изделиями, то комплектацию нового заказа можно будет выполнять нажатием одной кнопки "Скомплектовать" - и (если все составляющие заказ изделия были в наличии) заказ сразу готов к отгрузке! Или даже вообще без кнопки - комплектация заказов могла бы запускаться чисто автоматически, например каждую ночь по cron'у...

[san]

И еще один вопрос у меня возник "на свежую голову": в чем смысл комплектации заказа непроверенными и/или не прошедшими ОТК изделиями?

Это вопрос не ко мне, а к начальнику производства или замдирпокач или к директору.
Так организована работа ПТО:

• маркетинг выдаёт заказ
• производство выносит со склада коробку с нужными платами и добавляет их в заказ
• платы на складе хранятся в основном не проверенные и проверяются и проходят ОТК только по факту заказа (исключения бывают, но в основном так)

[san]

ticket:997#comment:14

Почему это не одновременно?

По твоему же описанию!

1. сначала она была отгружена по одному заказу;
2. потом она была возвращена;
3. потом она была отгружена по другому заказу.

Между пунктами 1 и 3 есть пункт 2, без которого пункт 3 был бы невозможен.

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

То есть как? Допустим, договор купли-продажи расторгнут, мы покупателю вернули деньги, а покупатель нам вернул плату. А в БД плата продолжает числиться проданной? Разве это правильно? Какой, в таком случае, в этом смысл? Хотя этот вопрос, наверное, уже ближе к теме тикета #874...

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

Отгруженный заказ это исторический снимок, говорящий о том что такого-то числа это отправили туда. Эта информация нужна, удалять её нельзя. Теоретическая вероятность возвращения платы в товар есть.

[san]

Replying to alx:

Может быть надо предусмотреть еще какое-то "проблемное" состояние заказа?

Внёс предложение в #1021

[alx]

Replying to san:

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

Ничто из сказанного не противоречит (предложенному мной) требованию уникальности номера.

Отгруженный заказ это исторический снимок, говорящий о том что такого-то числа это отправили туда. Эта информация нужна, удалять её нельзя. Теоретическая вероятность возвращения платы в товар есть.

Для исторических данных у нас ест другая таблица - history! А мое предложение касалось таблицы order-itams.

Насколько я понимаю и помню, в нашей БД принята такая логика: историческая информация записывается в таблицу history, а остальные таблицы содержат актуальную информацию об изделиях. В этой логике информация о том, что плата была помещена в заказ и отгружена потребителю, должна быть записана и храниться в таблице history. Когда плату вернули, в таблицу history должна быть добавлена новая запись о том, что плата возвращена, а из таблицы order-itams должен быть удален серийный номер возвращенной платы.

Если таблица order-itams не будет отражать текущее состояние заказа, то откуда это текущее состояние тогда брать? Получается, что в БД просто не будет этой информации! Захотела, допустим, АДС по своей инициативе расторгнуть договор и требует вернуть заказ - а какие платы должен вернуть покупатель, АДС и не знает, так как заказ - это, как ты сказал, "исторический слепок", не содержащий актуальной информации...

Если же говорить о заказах как о "слепках", то ИМХО это должен быть тогда не один слепок, а последовательность всех состояний заказа (состояний в широком смысле, а не в смысле поля state). То есть надо тогда применять некую схему версионирования заказов (смотри, например, как это сделано в Документоре для спецификаций). Я не думаю, что нам для заказов это нужно...

[san]

Для исторических данных у нас ест другая таблица - history!

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

а из таблицы order-itams должен быть удален серийный номер возвращенной платы.

В таком случае логичнее отгруженный заказ сразу удалять из order и order_items и "генерировать" отгруженные заказы по записям в истории плат...

[alx]

Replying to san:

Для исторических данных у нас ест другая таблица - history!

Ну да всё правильно, в таблице history хранится история изделий.

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

В таком случае логичнее отгруженный заказ сразу удалять из order и order_items и "генерировать" отгруженные заказы по записям в истории плат...

Так можно было бы сделать, если бы в заказ сразу включились уже существующие экземпляры плат. Но у нас же не так - у нас заказ изначально состоят из "обезличенных" позиций (типы плат без серийных номеров), и только потом, в процессе комплектации, эти позиции получают номера конкретных плат. У "обезличенных" позиций нет истории, поэтому "вытащить" их из таблицы history невозможно.

[san]

У "обезличенных" позиций нет истории, поэтому "вытащить" их из таблицы history невозможно.

Отгруженный заказ не может(не должен) содержать обезличенные позиции.

По-моему было бы логично использовать одну и ту же логику...

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

[alx]

Replying to alx:

В таком случае логичнее отгруженный заказ сразу удалять из order и order_items и "генерировать" отгруженные заказы по записям в истории плат...

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

Во-первых, согласен, так можно. Но это не имеет прямого отношения к моему предложению.

Во-вторых, твоя идея мне не кажется хорошей, так как одну и ту же информацию приложение должно будет "добывать" из БД разными способами в зависимости от этапа существования заказа: для еще не отгруженных - из таблиц orders и order_items, а для уже отгруженных - из таблицы history. Это неоправданно усложняет логику работы приложения, учитывая, что нужные данные и так есть в таблицах orders и order_items - достаточно их не удалять, и все будет работать единообразно. Но, повторяю, к моему предложению это уже не имеет отношения...

[alx]

Replying to san:

У "обезличенных" позиций нет истории, поэтому "вытащить" их из таблицы history невозможно.

Отгруженный заказ не может(не должен) содержать обезличенные позиции.

Еще раз прошу прощения. Я невнимательно прочитал твою мысль - Не заметил, что речь идет только об отгруженных заказах. Смотри ответ в моем предыдущем комментарии.

Насчет обезличенных плат в отгруженном заказе согласен с тобой, что это, наверное, неправильно. Поэтому корректирую смою мысль из comment:25: при возврате платы из таблицы order-itams должна удаляться вся соответствующая запись (а не заменяться серийный номер на NULL).

Потому что заказам "история" не нужна и незачем создавать лишние сущности.

Я не предлагал создавать историю для заказов. Ты меня, наверное, с кем-то путаешь. :) Что я предлагал, написано в ticket:997#comment:9.

Важно именно текущее состояние заказа, а в последнем состоянии "отгружен" заказ остаётся в таблице навечно.

Ага! Вот в этом я с тобой и не согласен. Я считаю, что состояние (в широком смысле) заказа на момент его перехода в состояние (в узком смысле) "отгружен" не обязательно является конечным. Даже через год после отгрузки заказа его состояние может измениться.

[san]

Даже через год после отгрузки заказа его состояние может измениться.

Таблица заказов задумывалась не как информация о том что реально сейчас у пользователя, а как информация о том что МЫ делаем и что отгрузили.
Что происходит с нашими платами у пользователя вообще нам не подконтрольно...

[alx]

Replying to san:

Даже через год после отгрузки заказа его состояние может измениться.

На всякий случай уточню, что я здесь имел в виду "состояние" в широком смысле - в заказ могут быть внесены изменения. Я не имел в виду, что заказ может перейти из состояния "отгружен" в состояние "прошел ОТК", например. :)

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

Раз когда-то было задумано так, значит надо делать только так и никак иначе? Это очень странный аргумент... :) А по-моему так это не аргумент вообще. Что мешает "перезадумать", если задумано было плохо (неудачно), и нашелся вариант лучше? По-моему ничто. А я считаю, что оставлять информацию о заказе в неактуальном состоянии - плохо. Например потому, что в БД не будет достоверной информации о том, какие из имеющихся в наличии изделий уже находятся в каком-то заказе, а какие - свободны и могут использоваться для комплектации новых заказов, а также не позволяет (по крайней мере, простыми способами) предотвратить ошибки, когда одной и той же платой комплектуется несколько заказов. Другие примеры того, почему это плохо, я уже приводил ранее, повторять не буду.

Что происходит с нашими платами у пользователя вообще нам не подконтрольно...

Бесспорно. Я и не предлагал контролировать, что происходит у пользователя с его платами. Что я предлагал, написано в ticket:997#comment:9.

[san]

и нашелся вариант лучше?

Я пока не вижу варианта лучше.

оставлять информацию о заказе в неактуальном состоянии

Это ты называешь такое состояние неактуальным, а по текущей концепции это вполне актуальное состояние отгруженного заказа.

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

Я не вижу тут проблемы. У изделий в таблице продукты есть поле owner - если оно имеет содержимое, то у платы есть хозяин, если содержимого нет, то хозяин АДС. Если плата отгружается в составе заказа, то owner устанавливается. Если плата возвращается к нам (и не в ремонт) owner очищается.
(пока в реальности вместо NULL в owner пишется АДС, но для однозначности отсутствия хозяина это будет исправлено на NULL)

ошибки, когда одной и той же платой комплектуется несколько заказов.

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

[san]

Вообще давно-давно на заре базастроения планировалось UID заказа записывать прямо в изделие в таблице products, но именно по причине того, что изделие может "присутствовать в нескольких заказах", от этой идеи отказались.

[alx]

Replying to san:

Я пока не вижу варианта лучше.

Уточни, пожалуйста, верно ли я тебя понял, что мой вариант, предложенный в ticket:997#comment:9, ты видишь, но не считаешь, что он лучше?

оставлять информацию о заказе в неактуальном состоянии

Это ты называешь такое состояние неактуальным, а по текущей концепции это вполне актуальное состояние отгруженного заказа.

Можно чуть подробнее про эту концепцию? Что это? Кто ее принял? Как можно с ней ознакомиться?

А лично ты с кем согласен - со мной или с концепцией? Предположим, кто-то купил у нас плату. А потом передумал, расторг договор и вернул плату обратно (а мы, конечно, вернули ему деньги). Как по-твоему, в этот момент плата им куплена или нет? По-моему, нет, не куплена, так как договор расторгнут, и все его последствия "откачены" назад, в исходное состояние. Упомянутая же тобой концепция, как я понял, считает, что плата все равно куплена. Так? Чья позиция по-твоему ближе к действительности - моя или концепции? Если моя, то, наверное, стоит (как минимум) изменить концепцию, или (как максимум) отказаться от этой концепции (если, конечно, ее не дал нам спустившийся с небес Господь Бог)... :)

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

Я не вижу тут проблемы. У изделий в таблице продукты есть поле owner - если оно имеет содержимое, то у платы есть хозяин, если содержимого нет, то хозяин АДС.

О, это уже более предметный разговор. :). Про поле owner я не подумал...

Если плата отгружается в составе заказа, то owner устанавливается.
Если плата возвращается к нам (и не в ремонт) owner очищается.

Ты говоришь, что это поле получает значение на этапе отгрузки. Следовательно, на этапе комплектации заказа это поле еще равно NULL как у "свободной" платы (которой не скомплектован ни один заказ), так и у "занятой" платы (уже "приписанной" какому-то заказу). И, следовательно, это поле не позволяет отличить "свободную" плату от "занятой". Как следствие, ничто не мешает нескольким сотрудникам (как, впрочем и одному) скомплектовать одной и той же платой несколько разных заказов... Тем более будет проблематично скомплектовать заказ автоматически...

Отвлеченное наблюдение: я сделал один запрос и вижу, что ВСЕ 9 с половиной тысяч имеющихся в БД изделий имеют в поле owner значение "АДС". Верно ли я понимаю, что за все время использования БД не было отгружено ни одного изделия? :)

ошибки, когда одной и той же платой комплектуется несколько заказов.

Вот с этим изначальным посылом с которого и начался диалог(с предложения добавить уникальность серийного номера в order_items), я согласен,

Неожиданный поворот... :) Чуть ли не целый день спорили о том, с чем, оказывается, оба согласны... :)

но не вижу красивого решения.

Верно ли я понял, что решение, предложенное в ticket:997#comment:9 (UNIQUE KEY `serial` (`serial`)) ты считаешь некрасивым?

[san]

Можно чуть подробнее про эту концепцию? Что это? Кто ее принял? Как можно с ней ознакомиться?
А лично ты с кем согласен - со мной или с концепцией? Предположим, кто-то купил у нас плату. А потом передумал, расторг договор и вернул плату обратно (а мы, конечно, вернули ему деньги). Как по-твоему, в этот момент плата им куплена или нет? По-моему, нет, не куплена, так как договор расторгнут, и все его последствия "откачены" назад, в исходное состояние. Упомянутая же тобой концепция, как я понял, считает, что плата все равно куплена. Так? Чья позиция по-твоему ближе к действительности - моя или концепции? Если моя, то, наверное, стоит (как минимум) изменить концепцию, или (как максимум) отказаться от этой концепции (если, конечно, ее не дал нам спустившийся с небес Господь Бог)... :)

Концепцию приняли на обсуждении с andrei, как с тем кто больше всего осведомлён о процессах в нашей компании.
Сформулировать можно примерно так:
Заказ рассматривается со стороны ПТО.
Cостояние заказа(в широком смысле) отражает как ПТО выполняет заказ.
После отгрузки заказа его состояние больше не меняется. И спустя какое-то время всегда можно увидеть "чем закончился" такой-то заказ выполненый ПТО - отгрузкой набора изделий. Что бы ни происходило дальше, ПТО отгрузил именно это, то что "зафиксировано" в отгруженном заказе.
Кажется я понял, наверное мы просто по разному воспринимаем слово заказ(как ты помнишь у нас в фирме часто встречается своя необычная терминология :) )
Так вот, под заказом в базе понимается "Заказ на производство", некое задание для ПТО, выданное отделом маркетинга, которое должно быть выполнено и результат отгружен указанному адресату. Что куплено, сколько заплачено и какие условия договора не входит в это понятие.

спустившийся с небес Господь Бог

Ну почти... зам директора по качеству

за все время использования БД не было отгружено ни одного изделия

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

Верно ли я понял, что решение, предложенное в ticket:997#comment:9 (UNIQUE KEY serial (serial)) ты считаешь некрасивым?

Нет. Но я не могу считать это решением, т.к. оно противоречит той самой "концепции".

[alx]

Replying to san:

Концепцию приняли на обсуждении с andrei,

......

спустившийся с небес Господь Бог

Ну почти... зам директора по качеству

Спасибо за пояснения. Я понял, что текущая концепция хранения заказов сознательно была принята не такой, как для изделий - вместо актуального состояния (как это принято для изделий) БД хранит состояние заказа на момент его отгрузки. И изменить ее нельзя, потому что зам директора хочет, чтобы было так (добавил его в копию, чтобы не получалось, что бы осуждаем его без него).

Верно ли я понял, что решение, предложенное в ticket:997#comment:9 (UNIQUE KEY serial (serial)) ты считаешь некрасивым?

Нет. Но я не могу считать это решением, т.к. оно противоречит той самой "концепции".

Понятно. В таком случае, предложение снимается, так как противоречит концерции зама директора. А я - человек маленький... :) Будем искать обходные пути...

В таком случае предлагается альтернативное решение которое ты сам уже поминал - записывать order-ID в таблицу products. По-моему это тоже вполне рабочее решение.

[san]

записывать order-ID в таблицу products

Т.е. при добавлении изделия в заказ, в изделие записывается его order_id, и такое изделие(с order_id не NULL) не может быть добавлено в другой заказ. При отгрузке или удалении изделия из заказа order_id удаляется.
Так?

[alx]

Replying to san:

Т.е. при добавлении изделия в заказ, в изделие записывается его order_id, и такое изделие(с order_id не NULL) не может быть добавлено в другой заказ. При отгрузке или удалении изделия из заказа order_id удаляется.
Так?

Не совсем.
Первая часть - верно. При добавлении изделия в заказ в его (изделия) поле order-id записывается ID заказа.
При отгрузке ничего не удаляется (иначе плату смогут добавить в другой заказ)! Удаляется order-ID в случаях типа:

• позицию исключили из заказа (изделие больше не нужно отгружать);
• изделие дефектное, и принято решение заменить его в позиции заказа другим (им можно скомплектовать, например, менее срочный заказ);
• после отгрузки заказа изделие вернули АДС (то есть оно свободно для комплектации другого заказа).

[san]

Разместил последнее предложение в #1026

[san]

На данный момент функционал требуемый тикетом реализован.

[san]

Milestone deleted