Сканер. Нужна помощь. Тип записей в историю при взятии изделия со склада, внесении на склад, изменении местоположения

[Denis_N]

Помогите пожалуйста продумать архитектуру

В новом интерфейсе Сканер, есть три разделяемые по моей логике действия: внесение на склад, взятие со склада, изменение местоположения изделия

Я забыл добавить в таблицу история запись о том, кто и что сделал с изделием

В истории тип столбца type_write следующий: set('record','otk','mismatch','testing','shipping','transform'). Не хочется записывать эти записи с типом record, потому что для пользователя, на мой взгляд, это не интуитивно. Хочется писать "Помещено на склад", "Взято со склада"

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

Вместо этого я бы хотел добавить еще три типа записей в столбец type_write в Истории: 'add_in_stock', 'take_out_stock', 'change_location'. И в старых записях с типом записи record, где было изменено местоположение, тип записи я бы изменил на change_location

[alx]

Replying to Denis_N:

Помогите пожалуйста продумать архитектуру

Прости, я дважды прочитал описание, но так и не понял, как я могу тебе помочь. Ты же не задаешь ни одного вопроса! :) В чем у тебя затруднение-то?

Так как

В новом интерфейсе Сканер, есть три разделяемые по моей логике действия: внесение на склад, взятие со склада, изменение местоположения изделия

Не знаю, что такое "интерфейс Сканер", но перечисленные действия и так фиксировались в БД с самого начала ее существования и без всякого сканера...

Я забыл добавить в таблицу история запись о том, кто и что сделал с изделием
В истории тип столбца type_write следующий: set('record','otk','mismatch','testing','shipping','transform'). Не хочется записывать эти записи с типом record, потому что для пользователя, на мой взгляд, это не интуитивно.

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

Хочется писать "Помещено на склад", "Взято со склада"

Что мешает так писать?

Можно рисовать этот псевдостатус, определяя по данным в столбце "местоположение" и комментарию,

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

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

Если требуется кроме собственно местоположения (склад) сохранять дополнительную уточняющую информацию (номер полки на складе), по-моему будет логично добавить к столбцу location столбец sublocation, и помещать уточняющую информацию туда.

Вместо этого я бы хотел добавить еще три типа записей в столбец type_write в Истории: 'add_in_stock', 'take_out_stock', 'change_location'. И в старых записях с типом записи record, где было изменено местоположение, тип записи я бы изменил на change_location

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

Во-первых, не понимаю, какой смысл менять в БД типы записей record на add_in_stock (название-то какое странное!), если при этом записи типа record, в которых не было перемещения, все равно останутся, и записи с перемещением, отличные от типа record, останутся тоже.

Во-вторых, непонятна цель добавления новых типов записей. Ну, допустим, добавил - и что дальше-то? Что-то от этого стало лучше? :) По-моему типы записей и так избыточны. Я, возможно, чего-то не знаю, но по-моему смысл имеют только тип записи otk, testing и mismatch. Все остальное, как мне кажется, можно было бы записывать просто без типа...

[Denis_N]

Спасибо, Алексей, что подключился к тикету
Replying to alx:

Прости, я дважды прочитал описание, но так и не понял, как я могу тебе помочь. Ты же не задаешь ни одного вопроса! :) В чем у тебя затруднение-то?

Да, ты прав, попробую добавить вопросы

В новом интерфейсе Сканер, есть три разделяемые по моей логике действия: внесение на склад, взятие со склада, изменение местоположения изделия

Не знаю, что такое "интерфейс Сканер", но перечисленные действия и так фиксировались в БД с самого начала ее существования и без всякого сканера...

В ревизии 374, я добавил страничку "Сканер" (интерфейс Сканер) https://trac.adc-line.ru/mc-04/changeset/374/base. У интерфейса есть три режима работы:

1. Занести на склад
2. Изменить местоположение
3. Инфо (не будем обсуждать в этом тикете)

В режиме "Занести на склад" - в таблицу продукты в столбец location записывается значение "склад", и в столбец shelfdrawer записывается значение номера полки/ящика на складе.
В режиме "Изменить местоположение" - в таблицу продукты в столбец location записывается новое значение местоположения, значение в столбце shelfdrawer очищается

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

Сейчас изменить только местоположение в продуктах можно через интерфейс Возврат. Также при изменении местоположения через и-с Возврат, в Историю будет занесена запись с типом "record" и указано местоположение. И понять я могу, что изделие было перемещено по этим двум критериям и по местоположению в более ранних записях, что не интуитивно.

Может быть стоит добавить в столбец type_write новые типы записей для событий (когда изделие занесено на склад, когда изменено местоположение, когда изделие забрали со склада), а не использовать record? Какие? Писать номер полки/ящика в поле "комментарий" или создать новый столбец или другим способом?

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

Ты предлагаешь по каким-то изменениям в Истории анализировать действие, которое было совершено с изделием и выводить его пользователю? Например, перименовать "Тип записи" в "Действие", а значение Отгрузка, в "Отгружено"? Если нет, то какие варианты ты можешь предложить?

Хочется писать "Помещено на склад", "Взято со склада"

Что мешает так писать?

Ничего не мешает обработать. Вопрос в том, что лучше сделать: анализировать по нескольким столбцам, определять, что произошло с платой и выводить действие "Помещено на склад"/"Взято со склада"/"Изменилось местоположение" или добавить эти три варианты типа записей в столбец "Тип записи" и на их основе определять, что произошло с изделием

Можно рисовать этот псевдостатус, определяя по данным в столбце "местоположение" и комментарию,

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

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

Отыскать можно по критериям таким, как тип записи и комментарий. Например, тип записи record и комментарий содержащий значение полки или ящика, которое можно проверить регулярным выражением

Если требуется кроме собственно местоположения (склад) сохранять дополнительную уточняющую информацию (номер полки на складе), по-моему будет логично добавить к столбцу location столбец sublocation, и помещать уточняющую информацию туда.

Вместо этого я бы хотел добавить еще три типа записей в столбец type_write в Истории: 'add_in_stock', 'take_out_stock', 'change_location'. И в старых записях с типом записи record, где было изменено местоположение, тип записи я бы изменил на change_location

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

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

Во-первых, не понимаю, какой смысл менять в БД типы записей record на add_in_stock (название-то какое странное!), если при этом записи типа record, в которых не было перемещения, все равно останутся, и записи с перемещением, отличные от типа record, останутся тоже.

Записи с типом record и не пустым столбцом location я предлагаю заменить на тип change_location

Во-вторых, непонятна цель добавления новых типов записей. Ну, допустим, добавил - и что дальше-то? Что-то от этого стало лучше? :) По-моему типы записей и так избыточны. Я, возможно, чего-то не знаю, но по-моему смысл имеют только тип записи otk, testing и mismatch. Все остальное, как мне кажется, можно было бы записывать просто без типа...

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

[alx]

Replying to Denis_N:

В ревизии 374, я добавил страничку "Сканер" (интерфейс Сканер) https://trac.adc-line.ru/mc-04/changeset/374/base. У интерфейса есть три режима работы:

1. Занести на склад
2. Изменить местоположение

А, понятно.

Странно, конечно, что "Занести на склад" выделено в отдельный режим, хотя является всего лишь частным случаем изменения местоположения (когда новым местоположением является склад), но это наверное не относится к теме тикета... :)

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

Зачем столько критериев? Разве одного первого критерия (наличия не пустого поля location) недостаточно?

что не интуитивно.

И не должно быть интуитивно, это же "внутренняя кухня" системы, об этом никому (кроме разработчика) знать не обязательно...

Может быть стоит добавить в столбец type_write новые типы записей для событий (когда изделие занесено на склад, когда изменено местоположение, когда изделие забрали со склада), а не использовать record?

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

Какие?

Никакие. Я бы вместо этого и некоторые существующие убрал... :)

Писать номер полки/ящика в поле "комментарий" или создать новый столбец или другим способом?

Думаю, создать новый столбец. Собственно, как я вижу из комментария к r374/base, такой столбец уже создан...

Ты предлагаешь по каким-то изменениям в Истории анализировать действие, которое было совершено с изделием и выводить его пользователю?

Я этого не предлагал, но высказал мнение о том, что так было бы для пользователя лучше и удобнее. По-моему это очевидно. Ну сам посуди - откуда пользователю знать, что означает значение в поле location? Разве где-то документировано, когда и в каких случаев какое значение оно принимает? Конечно, он этого не знает, поэтому и интерпретировать отображаемые ему значения не может! Для пользователя надо писать естественным языком, типа "изделие передано разработчикам" или "изделие отгружено заказчику", а не требовать, чтобы он сам интерпретировал почти сырые данные из таблиц БД ("почти" - только потому что название столбца переведено)...

Например, перименовать "Тип записи" в "Действие", а значение Отгрузка, в "Отгружено"?

Как и что называется внутри БД, "под капотом" - твое дело (так как ты единственный разработчик), и
переименовывать это я не предлагал. Было бы, конечно, хорошо изначально использовать более понятные названия. Одни только "performance", "type_write" и "mismatch" чего стоят! :) Но ты уже, наверное, привык к таким, какие есть (даже я как-то привык), и если переименовать теперь - наверное станет только хуже, ты начнешь путаться, вспоминая, что это было раньше за поле или значение такое. :) Наверное лучше оставить такие названия, какие "прижились".

Если нет, то какие варианты ты можешь предложить?

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

Или вот, например, столбцы "N" и "№" - они зачем пользователю нужны? Что это вообще такое? Вот, допустим, видит пользователь, что в некоей записи истории поле "N" имеет значение 81902. Что полезного он с этим числом сделает? Для чего оно ему? Он куда-то это число должен будет ввести? Или произвести с этим числом какие-то вычисления? Я правда не знаю и не понимаю... Я смутно догадываюсь (как тот пользователь в предыдущем абзаце), что это какие-то внутренние идентификаторы строк таблиц. Если это так, то пользователю все это нафиг не нужно - это служебные поля, и интерпретировать их должен компьютер, а не человек, и тогда я предлагаю из веб-интерфейса это просто убрать...

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

Хочется писать "Помещено на склад", "Взято со склада"

Что мешает так писать?

Ничего не мешает обработать. Вопрос в том, что лучше сделать: анализировать по нескольким столбцам, определять, что произошло с платой и выводить действие "Помещено на склад"/"Взято со склада"/"Изменилось местоположение" или добавить эти три варианты типа записей в столбец "Тип записи" и на их основе определять, что произошло с изделием

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

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

Отыскать можно по критериям таким, как тип записи и комментарий.

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

Например, тип записи record и комментарий содержащий значение полки или ящика, которое можно проверить регулярным выражением

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

Такое желание мне непонятно.

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

Непонятно, зачем тебе для условия тип записи. По-моему тип записи для условия не нужен. Для условия достаточно единственного критерия - поля location. Если в нем не NULL, значит изделие было перемещено.

Записи с типом record и не пустым столбцом location я предлагаю заменить на тип change_location

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

по-моему смысл имеют только тип записи otk, testing и mismatch. Все остальное, как мне кажется, можно было бы записывать просто без типа...

Записи без типа - это усложнение условия в выводе из бд.

Не понимаю, как это может усложнить условие. Во-первых, это же просто замена одного значения ('record') другим (NULL). И то, и другое проверяется одним оператором (точнее, в случае NULL - функцией). Или ты считаешь усложнением то, что для набора "ISNULL()" требуется больше нажатий клавиш чем для набора "="? :)

Во-вторых, а зачем вообще может потребоваться проверять type_write на NULL (или 'record') при выводе? Единственное значение, на которое по-моему может потребоваться проверка - это на 'mismatch' (для группировки записей, относящихся к одному несоответствию)...

Когда нужно применить фильтрацию

Для применения какой фильтрации требуется проверять type_write на 'record' или NULL? Мы же говорим о выводе истории изделия - какая может быть фильтрация при выводе истории? Ты не путаешь ли с выводом списка изделий?

и прочее.

Не понимаю, для какого такого прочего вывода истории изделия может потребоваться проверка type_write на 'record' или NULL.

Нужно будет для каждого типа писать отдельное условия,

Во-первых, зачем?

Во-вторых, а сейчас не надо? Если да, то почему станет надо, если сократить количество типов? Звучит контр-интуитивно...

понимать критерии по которым понимать тип,

Прости, не понимаю, что значит "понимать тип", и что такое "критерии, по которым его понимают". :)

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

Что такое "массовое применение условий" я, уж прости, тоже не понимаю. :)