Opened 2 years ago
Last modified 19 months ago
#997 assigned задача
Информация по проекту БД изделий АДС
Reported by: | san | Owned by: | san |
---|---|---|---|
Priority: | blocker | Component: | БД изделий АДС |
Keywords: | Cc: |
Description (last modified by )
Формат серийных номеров изделий:
A12345 - латинская заглавная буква и 5 цифр
12345 - 5 цифр
Б1234 - русская заглавная Б и 4 цифры
Р123456 - русская заглавная Р[эр] и 6 цифр
Формат таблиц в БД:
MariaDB [adcproducts]> Show columns from `products`; +----------+-------------------------------------------------------------------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +----------+-------------------------------------------------------------------------+------+-----+---------+----------------+ | UID | int(32) | NO | PRI | NULL | auto_increment | | type | varchar(100) | YES | | NULL | | | name | varchar(100) | YES | | NULL | | | serial | varchar(100) | NO | UNI | NULL | | | date | date | YES | | NULL | | | owner | varchar(100) | YES | | NULL | | | location | enum('stock','shipped','develop','isolator','nelikvid','repair','work') | YES | | NULL | | | testing | enum('ok','fail','notest') | YES | | notest | | | otk | enum('ok','fail','nocheck') | YES | | nocheck | | | mismatch | enum('yes','no') | YES | | no | | | repair | varchar(100) | No | | no | | | comment | text | YES | | NULL | | +----------+-------------------------------------------------------------------------+------+-----+---------+----------------+ 12 rows in set (0.001 sec) MariaDB [adcproducts]> Show columns from `history`; +--------------+---------------------------------------------------------------------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +--------------+---------------------------------------------------------------------------+------+-----+---------+----------------+ | UID | int(32) | YES | | NULL | | | worker | varchar(100) | YES | | NULL | | | date | datetime | YES | | NULL | | | type_write | enum('record','otk','mismatch','testing','repair','shipping','transform') | YES | | NULL | | | order_from | varchar(100) | YES | | NULL | | | whom_order | varchar(100) | YES | | NULL | | | location | enum('stock','shipped','develop','isolator','nelikvid','repair','work') | YES | | NULL | | | number_order | int(11) | YES | | NULL | | | status | enum('ok','fail') | YES | | NULL | | | comment | text | YES | | NULL | | | N | int(11) | NO | PRI | NULL | auto_increment | +--------------+---------------------------------------------------------------------------+------+-----+---------+----------------+ 12 rows in set (0.002 sec) MariaDB [adcproducts]> Show columns from `users`; +----------+--------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +----------+--------------+------+-----+---------+-------+ | user | varchar(100) | YES | UNI | NULL | | | worker | varchar(100) | YES | | NULL | | | password | varchar(100) | YES | | NULL | | | root | varchar(100) | YES | | NULL | | +----------+--------------+------+-----+---------+-------+ 4 rows in set (0.001 sec) MariaDB [adcproducts]> Show columns from `list_of_products`; +--------+--------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +--------+--------------+------+-----+---------+----------------+ | uid | int(32) | NO | PRI | NULL | auto_increment | | name | varchar(100) | YES | UNI | NULL | | | type | varchar(100) | YES | | NULL | | | parent | int(32) | YES | | NULL | | +--------+--------------+------+-----+---------+----------------+ 4 rows in set (0.001 sec) MariaDB [adcproducts]> Show columns from `orders`; +-------------+---------------------------------------------------------------+------+-----+---------------------+-------+ | Field | Type | Null | Key | Default | Extra | +-------------+---------------------------------------------------------------+------+-----+---------------------+-------+ | UID | int(32) | YES | UNI | NULL | | | datetime | datetime | NO | | current_timestamp() | | | deadline | date | YES | | NULL | | | status | enum('created','accept','completed','verify','otk','shipped') | YES | | NULL | | | composition | text | YES | | NULL | | | recipient | varchar(200) | YES | | NULL | | | comment | text | YES | | NULL | | +-------------+---------------------------------------------------------------+------+-----+---------------------+-------+ 7 rows in set (0.001 sec) MariaDB [adcproducts]> Show columns from `order-items`; +------------------+--------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +------------------+--------------+------+-----+---------+-------+ | order_id | int(32) | NO | MUL | NULL | | | serial | varchar(100) | YES | MUL | NULL | | | type | varchar(100) | NO | | NULL | | | name | varchar(100) | NO | | NULL | | | parent | varchar(100) | YES | | NULL | | | record_checkmark | tinyint(1) | NO | | 0 | | +------------------+--------------+------+-----+---------+-------+ 6 rows in set (0.001 sec)
Права пользователей:
accept - добавление изделий в базу
mismatch - добавление несоответствий
repair - устранение несоответствий
refand - приём плат в возврат или в ремонт от заказчика
testing -проверка плат
otk - ОТК
shipment - отгрузка
transform - преобразование изделия в другое изделие
createorder - создание и редактирование заказа
Change History (37)
comment:1 by , 2 years ago
Description: | modified (diff) |
---|
follow-up: 5 comment:2 by , 2 years ago
comment:3 by , 2 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:4 by , 2 years ago
Owner: | changed from | to
---|
comment:5 by , 2 years ago
Replying to san:
Денис: Нужно добавить новый тип записи transform
alter table history modify column type_write enum ('record','otk','mismatch','testing','repair','shipping','transform');
p.s. Наверное и право transform тоже нужно добавить в список
Добавил
comment:6 by , 2 years ago
Description: | modified (diff) |
---|
comment:7 by , 2 years ago
Для создания и изменения заказа пользователю необходимо добавить права "createorder" в БД.
Также для изменения заказа, необходимо создать столбец в order-items:
alter table order-items add record_checkmark boolean not null default false
comment:8 by , 2 years ago
Я обнаружил, что поле number_order
в таблице history
не имеет FOREIGN KEY, что позволяет занести в него несуществующий номер заказа.
Предлагаю добавить примерно такой ключ:
FOREIGN KEY (`number_order`) REFERENCES `orders` (`UID`)
.
comment:9 by , 2 years ago
В таблице order-items
поле serial
не имеет UNIQUE KEY. Мне кажется, это неправильно, ведь одно изделие не может быть продано более одного раза...
Предлагаю добавить в таблице order-items
ключ UNIQUE KEY `serial` (`serial`)
.
follow-up: 11 comment:10 by , 2 years ago
ведь одно изделие не может быть продано более одного раза...
Теоретически может.
comment:11 by , 2 years ago
Replying to san:
ведь одно изделие не может быть продано более одного раза...
Теоретически может.
Так-то может и практически. :) Это называется "мошенничество".
Хорошо, поправлюсь: не "не может", а "не должна".
follow-up: 13 comment:12 by , 2 years ago
Плата может быть отгружена, например на тестовую эксплуатацию заказчику и вернуться к нам обратно через год.
Затем мы можем отгрузить такую плату(по согласованию с заказчиком) ещё куда-то.
comment:13 by , 2 years ago
Replying to san:
Плата может быть отгружена, например на тестовую эксплуатацию заказчику и вернуться к нам обратно через год.
Затем мы можем отгрузить такую плату(по согласованию с заказчиком) ещё куда-то.
Все верно, согласен, такое возможно. Но это никак не противоречит требованию уникальности номера, так как плата присутствует в составе разных заказов не одновременно. :)
Хорошо. Снова поправлю формулировку: в один и тот же момент времени плата не должна присутствовать в заказах более одного раза.
follow-up: 15 comment:14 by , 2 years ago
Почему это не одновременно?
Заказ который мы отгрузили, он ведь не удаляется из базы, и плата присутствует в его составе.
comment:15 by , 2 years ago
Replying to san:
Почему это не одновременно?
По твоему же описанию!
- сначала она была отгружена по одному заказу;
- потом она была возвращена;
- потом она была отгружена по другому заказу.
Между пунктами 1 и 3 есть пункт 2, без которого пункт 3 был бы невозможен.
Заказ который мы отгрузили, он ведь не удаляется из базы, и плата присутствует в его составе.
То есть как? Допустим, договор купли-продажи расторгнут, мы покупателю вернули деньги, а покупатель нам вернул плату. А в БД плата продолжает числиться проданной? Разве это правильно? Какой, в таком случае, в этом смысл? Хотя этот вопрос, наверное, уже ближе к теме тикета #874...
follow-up: 17 comment:16 by , 2 years ago
С какой целью в products
присутствует столбец type
, если есть таблица list_of_products
, устанавливающая однозначное соответствие name
-> type
?
Создал тикет #1027.
comment:17 by , 2 years ago
Replying to alx:
С какой целью в
products
присутствует столбецtype
, если есть таблицаlist_of_products
, устанавливающая однозначное соответствиеname
->type
?
Это рудимент, но часть интерфейсов ещё использует его, постепенно Денис устранит зависимость.
follow-up: 19 comment:18 by , 2 years ago
Случайно заметил вопросы Алексея на гитхабе, предлагаю всё-таки базу обсуждать здесь:
Для номенклатуры изделий в базе с некоторых пор есть договорённость, что каждое исполнение платы заведено в базу как отдельный тип изделия, приведу пример платы S-port, у неё по КД есть три исполнения с номерами 3, 5 и 12. В номенклатуре базы заведены 4 типа изделия: S-port (просто доска и плата неопределённого исполнения. когда часть элементов ещё не запаяна, полуфабрикат короче)
Хм... А для чего в номенклатуру изделий занесено то, что изделием не является (полуфабрикат)?
Плата на этом этапе может получить серийный номер и лечь на склад в виде полуфабриката, а нужные пару резисторов конкретного исполнения запаяют уже непосредственно при выполнении заказа, "посчитать" в базе такое изделие всё-равно нужно.
При таком подходе столбец Исп. просто не нужен и его можно удалить.
Хорошо. Есть, например, в БД изделие (плата) с серийным номером E02528. Как узнать номер исполнения этой платы (я его знаю, интересен именно предлагаемый порядок действий)?
Номер исполнения этой платы неизвестен, т.к. в номенклатуре присутствует только одно исполнение VE-02, а на самом деле их два.
comment:19 by , 2 years ago
Replying to san:
При таком подходе столбец Исп. просто не нужен и его можно удалить.
Есть, например, в БД изделие (плата) с серийным номером E02528. Как узнать номер исполнения этой платы?
Номер исполнения этой платы неизвестен, т.к. в номенклатуре присутствует только одно исполнение VE-02, а на самом деле их два.
Тогда получается, что столбец "вариант исполнения" все-таки нужен, раз без него невозможно установить вариант исполнения изделия!
follow-up: 21 comment:20 by , 2 years ago
невозможно установить вариант исполнения изделия!
Это невозможно вследствие ошибки (отсутствия исполнения в номенклатуре). Наличие столбца не исключит возможность ошибки при указании номера.
comment:21 by , 2 years ago
Replying to san:
невозможно установить вариант исполнения изделия!
Это невозможно вследствие ошибки (отсутствия исполнения в номенклатуре). Наличие столбца не исключит возможность ошибки при указании номера.
Согласен. Но что теперь делать с этими ошибками? Я вот посмотрел другую наугад взятую плату (BS-220) и обнаружил, что из четырех существующих исполнений платы в list_of_products
присутствует только три (а, скорее всего, два, так как просто "BS-220" - это, насколько я понимаю, та самая "заготовка")... Это уже, конечно, не по теме тикета, но может быть стоит, как минимум, внести в таблицу list_of_products
все исполнения всех изделий? А как максимум - перепроверить соответствие реальных исполнений имеющимся в БД... Хочется верить, что за все время существования БД действительно не было изготовлено не одной платы VE-02 базового исполнения, и все имеющиеся на складе 210 плат действительно имеют вариант исполнения 1 (а иначе бы сразу поступила жалоба сотрудника на отсутствие в номенклатуре базового исполнения). Но...
follow-up: 24 comment:22 by , 2 years ago
Я хотел сначала сделать всё логично и у каждого изделия указывать его исполнение, но на практике этот подход столкнулся с некоторыми проблемами:
- В нашей кд исполнения сами по себе часто вызывают путаницу, да ещё и меняются со временем, например GE-04 недавно ещё была исполнением 1 платы PE-14, сейчас GE-04 это уже почти отдельное изделие, только децимальный номер указывает на связь.
- Производству удобнее оперировать обозначениями изделий в заказе, т.к. заказ им выдаётся именно в таких терминах и удобнее чтобы в базу они вносились в таком виде.
В итоге номенклатура базы, практически совпадает с перечнем из прайс-листа(обозначениями в заказах)
что теперь делать с этими ошибками
Пока всё решается по факту обнаружения, вот ты указал что отсутствует базовое исполнение для VE-02 - я добавлю в номенклатуру это исполнение (хотя у меня сомнения как его назвать... в прайсе такой отдельной позиции нет, VE-02-00 и VE-02-01 будут непонятны производству, плодить сущность в виде какого-нибудь VE-02-VIP тоже не хочется)
BS-220 сейчас им
comment:23 by , 2 years ago
Продолжение:)
BS-220 сейчас имеет два обозначения в заказе BS-220-60 и BS-220-100 все проходящие через производство платы дорабатываются до последних исполнений(3 и 4)
comment:24 by , 23 months ago
Replying to san:
- В нашей кд исполнения сами по себе часто вызывают путаницу, да ещё и меняются со временем,
например GE-04 недавно ещё была исполнением 1 платы PE-14, сейчас GE-04 это уже почти отдельное изделие, только децимальный номер указывает на связь.
ИМХО у тебя есть все необходимые возможности и полномочия для наведения порядка в КД. Вопрос только в желании и воле... :)
- Производству удобнее оперировать обозначениями изделий в заказе, т.к. заказ им выдаётся именно в таких терминах и удобнее чтобы в базу они вносились в таком виде.
Я уже по твоему совету передал менеджменту предложение отказаться от такой практики. Так что, возможно, эта проблема будет устранена.
базовое исполнение для VE-02 - я добавлю в номенклатуру это исполнение (хотя у меня сомнения как его назвать... в прайсе такой отдельной позиции нет, VE-02-00 и VE-02-01 будут непонятны производству, плодить сущность в виде какого-нибудь VE-02-VIP тоже не хочется)
Это - последствия принятых менеджментом решений. Например о том, что изделия нельзя обозначать в заказах их настоящими именами, а надо почему-то выдумывать другие обозначения (при этом для некоторых изделий этот запрет почему-то не действует!!!)...
Но даже при этом ведь можно было сделать наименования и обозначения отличимыми друг от друга с одного взгляда - например начинать все обозначения с символа "#" - тогда было бы сразу видно, что, например, "#AB-34" - это обозначение в заказе, а, например, "AB-34" - это наименование... Но нет, обозначения в заказах решили делать неотличимыми от наименований изделий (вплоть до их полного совпадения с наименованиями других изделий!), так что без дополнительных пояснений неясно - наименование это или обозначение...
И, кстати, добавлять в номенклатуру (list_of_products
) плату VE-02 исполнения 1 не надо - она там уже есть.
follow-up: 27 comment:25 by , 23 months ago
ИМХО у тебя есть все необходимые возможности и полномочия для наведения порядка в КД. Вопрос только в желании и воле... :)
С этим я согласен, главное определить что такое "порядок" :-D
Это - последствия принятых менеджментом решений. Например о том, что изделия нельзя обозначать в заказах их настоящими именами, а надо почему-то выдумывать другие обозначения (при этом для некоторых изделий этот запрет почему-то не действует!!!)...
Да вообщем то никто специально другие названия не выдумывал, это просто результат несогласованной работы отделов, маркетинг думал что разработка делает плату с названием "Вася", а разработка думала что плата называется "Петя". В итоге оба названия "настоящие", одно согласно кд, другое согласно договорам.
comment:26 by , 23 months ago
Description: | modified (diff) |
---|
comment:27 by , 23 months ago
Description: | modified (diff) |
---|
Replying to san:
главное определить что такое "порядок" :-D
Думаю, ты справишься. :)
Начать можно с того, что нам нужен архив КД. То, что есть, как ты много раз мог убедиться, это просто "свалка" файлов, не соответствующая даже требованиям нашего собственного стандарта. На мой (некомпетентный) взгляд, нам надо создать новый, чистый (пустой) архив, и начинать как бы "сдавать" туда уже имеющиеся документы - по всем правилам и требованиям. Подозреваю, что половина из них не сможет быть сдана... :)
Да вообщем то никто специально другие названия не выдумывал, это просто результат несогласованной работы отделов, маркетинг думал что разработка делает плату с названием "Вася", а разработка думала что плата называется "Петя". В итоге оба названия "настоящие", одно согласно кд, другое согласно договорам.
Упал на нож 18 раз. :)
Во-первых, случайно это могло произойти один - два раза. У нас же таких случаев много больше.
Во-вторых, если кто-то ошибся - ничто не мешало бы исправить ошибку, когда она была обнаружена. Однако было сказано (с твоих же слов), что называть (как минимум, некоторые) платы и обозначать их в заказах одинаково - нельзя...
comment:28 by , 23 months ago
Description: | modified (diff) |
---|
Возвращаю изменение, случайно откаченное предыдущим комментарием в результате гонок.
comment:29 by , 23 months ago
Priority: | major → blocker |
---|
comment:30 by , 23 months ago
В #963 я предложил изменить тип столбца comment
таблицы history
на MEDIUMTEXT или LONGTEXT.
comment:31 by , 22 months ago
Description: | modified (diff) |
---|
Добавил transform и record_checkmark (и вообще всю order-items)
comment:35 by , 19 months ago
Description: | modified (diff) |
---|---|
Summary: | Формат таблиц в БД → Информация по проекту БД изделий АДС |
follow-up: 37 comment:36 by , 19 months ago
Replying to san:
Формат серийных номеров изделий:
A12345 - латинская заглавная буква и 5 цифр
12345 - 5 цифр
Б1234 - русская заглавная Б и 4 цифры
Р123456 - русская заглавная Р[эр] и 6 цифр
Это не полный перечень вариантов. Как минимум, есть еще серийные номера из 6 цифр.
comment:37 by , 19 months ago
Replying to alx:
есть еще серийные номера из 6 цифр.
Выяснилось (со слов san), что это был не серийный номер, а дата, в которой почему-то отсутствовали разделяющие элементы точки.
Денис: Нужно добавить новый тип записи transform
alter table history modify column type_write enum ('record','otk','mismatch','testing','repair','shipping','transform');
p.s. Наверное и право transform тоже нужно добавить в список