Формат таблиц в БД

[san]

Здесь описан формат таблиц в БД, при необходимости изменить формат - пишем в этот тикет.

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    |                |
| perfomance | 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  |     | NULL    |                |
| mismatch   | enum('yes','no')                                                        | YES  |     | no      |                |
| repair     | varchar(100)                                                            | YES  |     | NULL    |                |
| comment    | text                                                                    | YES  |     | NULL    |                |
+------------+-------------------------------------------------------------------------+------+-----+---------+----------------+
13 rows in set (0.002 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 | varchar(100)                                                  | YES  |     | NULL    |       |
| status       | enum('ok','fail')                                             | YES  |     | NULL    |       |
| comment      | text                                                          | YES  |     | NULL    |       |
| protocol     | varchar(100)                                                  | YES  |     | NULL    |       |
+--------------+---------------------------------------------------------------+------+-----+---------+-------+
10 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 |
+-------+--------------+------+-----+---------+-------+
| name  | varchar(100) | YES  |     | NULL    |       |
| type  | varchar(100) | YES  |     | NULL    |       |
+-------+--------------+------+-----+---------+-------+
2 rows in set (0.004 sec)

MariaDB [adcproducts]> SHOW columns from orders;
+-------------+------------------+------+-----+---------+-------+
| Field       | Type             | Null | Key | Default | Extra |
+-------------+------------------+------+-----+---------+-------+
| UID         | int(32)          | YES  | UNI | NULL    |       |
| composition | text             | YES  |     | NULL    |       |
| recipient   | varchar(100)     | YES  |     | NULL    |       |
| shipped     | enum('yes','no') | YES  |     | NULL    |       |
| comment     | text             | YES  |     | NULL    |       |
+-------------+------------------+------+-----+---------+-------+
5 rows in set (0.003 sec)

Права: accept,mismatch,otk,refand,repair,shipment,testing,transform,createorder

[san]

Денис: Нужно добавить новый тип записи transform
alter table history modify column type_write enum ('record','otk','mismatch','testing','repair','shipping','transform');

p.s. Наверное и право transform тоже нужно добавить в список

[san]

Replying to san:

Денис: Нужно добавить новый тип записи transform
alter table history modify column type_write enum ('record','otk','mismatch','testing','repair','shipping','transform');

p.s. Наверное и право transform тоже нужно добавить в список

Добавил

[san]

r51/base

Для создания и изменения заказа пользователю необходимо добавить права "createorder" в БД.
Также для изменения заказа, необходимо создать столбец в order-items:
alter table order-items add record_checkmark boolean not null default false

[alx]

Я обнаружил, что поле number_order в таблице history не имеет FOREIGN KEY, что позволяет занести в него несуществующий номер заказа.

Предлагаю добавить примерно такой ключ:

FOREIGN KEY (`number_order`) REFERENCES `orders` (`UID`).

[alx]

В таблице order-items поле serial не имеет UNIQUE KEY. Мне кажется, это неправильно, ведь одно изделие не может быть продано более одного раза...

Предлагаю добавить в таблице order-items ключ UNIQUE KEY `serial` (`serial`).

[san]

ведь одно изделие не может быть продано более одного раза...

Теоретически может.

[alx]

Replying to san:

ведь одно изделие не может быть продано более одного раза...

Теоретически может.

Так-то может и практически. :) Это называется "мошенничество".

Хорошо, поправлюсь: не "не может", а "не должна".

[san]

Плата может быть отгружена, например на тестовую эксплуатацию заказчику и вернуться к нам обратно через год.
Затем мы можем отгрузить такую плату(по согласованию с заказчиком) ещё куда-то.

[alx]

Replying to san:

Плата может быть отгружена, например на тестовую эксплуатацию заказчику и вернуться к нам обратно через год.
Затем мы можем отгрузить такую плату(по согласованию с заказчиком) ещё куда-то.

Все верно, согласен, такое возможно. Но это никак не противоречит требованию уникальности номера, так как плата присутствует в составе разных заказов не одновременно. :)

Хорошо. Снова поправлю формулировку: в один и тот же момент времени плата не должна присутствовать в заказах более одного раза.

[san]

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

[alx]

Replying to san:

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

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

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

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

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

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

[alx]

С какой целью в products присутствует столбец type, если есть таблица list_of_products, устанавливающая однозначное соответствие name -> type?

Создал тикет #1027.

[san]

Replying to alx:

С какой целью в products присутствует столбец type, если есть таблица list_of_products, устанавливающая однозначное соответствие name -> type?

Это рудимент, но часть интерфейсов ещё использует его, постепенно Денис устранит зависимость.

[san]

Случайно заметил вопросы Алексея на ​гитхабе, предлагаю всё-таки базу обсуждать здесь:

Для номенклатуры изделий в базе с некоторых пор есть договорённость, что каждое исполнение платы заведено в базу как отдельный тип изделия, приведу пример платы S-port, у неё по КД есть три исполнения с номерами 3, 5 и 12. В номенклатуре базы заведены 4 типа изделия: S-port (просто доска и плата неопределённого исполнения. когда часть элементов ещё не запаяна, полуфабрикат короче)

Хм... А для чего в номенклатуру изделий занесено то, что изделием не является (полуфабрикат)?

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

При таком подходе столбец Исп. просто не нужен и его можно удалить.

Хорошо. Есть, например, в БД изделие (плата) с серийным номером E02528. Как узнать номер исполнения этой платы (я его знаю, интересен именно предлагаемый порядок действий)?

Номер исполнения этой платы неизвестен, т.к. в номенклатуре присутствует только одно исполнение VE-02, а на самом деле их два.

[alx]

Replying to san:

При таком подходе столбец Исп. просто не нужен и его можно удалить.

Есть, например, в БД изделие (плата) с серийным номером E02528. Как узнать номер исполнения этой платы?

Номер исполнения этой платы неизвестен, т.к. в номенклатуре присутствует только одно исполнение VE-02, а на самом деле их два.

Тогда получается, что столбец "вариант исполнения" все-таки нужен, раз без него невозможно установить вариант исполнения изделия!

[san]

невозможно установить вариант исполнения изделия!

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

[alx]

Replying to san:

невозможно установить вариант исполнения изделия!

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

Согласен. Но что теперь делать с этими ошибками? Я вот посмотрел другую наугад взятую плату (BS-220) и обнаружил, что из четырех существующих исполнений платы в list_of_products присутствует только три (а, скорее всего, два, так как просто "BS-220" - это, насколько я понимаю, та самая "заготовка")... Это уже, конечно, не по теме тикета, но может быть стоит, как минимум, внести в таблицу list_of_products все исполнения всех изделий? А как максимум - перепроверить соответствие реальных исполнений имеющимся в БД... Хочется верить, что за все время существования БД действительно не было изготовлено не одной платы VE-02 базового исполнения, и все имеющиеся на складе 210 плат действительно имеют вариант исполнения 1 (а иначе бы сразу поступила жалоба сотрудника на отсутствие в номенклатуре базового исполнения). Но...

[san]

Я хотел сначала сделать всё логично и у каждого изделия указывать его исполнение, но на практике этот подход столкнулся с некоторыми проблемами:

• В нашей кд исполнения сами по себе часто вызывают путаницу, да ещё и меняются со временем, например GE-04 недавно ещё была исполнением 1 платы PE-14, сейчас GE-04 это уже почти отдельное изделие, только децимальный номер указывает на связь.
• Производству удобнее оперировать обозначениями изделий в заказе, т.к. заказ им выдаётся именно в таких терминах и удобнее чтобы в базу они вносились в таком виде.

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

что теперь делать с этими ошибками

Пока всё решается по факту обнаружения, вот ты указал что отсутствует базовое исполнение для VE-02 - я добавлю в номенклатуру это исполнение (хотя у меня сомнения как его назвать... в прайсе такой отдельной позиции нет, VE-02-00 и VE-02-01 будут непонятны производству, плодить сущность в виде какого-нибудь VE-02-VIP тоже не хочется)

BS-220 сейчас им

[san]

Продолжение:)
BS-220 сейчас имеет два обозначения в заказе BS-220-60 и BS-220-100 все проходящие через производство платы дорабатываются до последних исполнений(3 и 4)

[alx]

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 не надо - она там уже есть.

[san]

ИМХО у тебя есть все необходимые возможности и полномочия для наведения порядка в КД. Вопрос только в желании и воле... :)

С этим я согласен, главное определить что такое "порядок" :-D

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

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