Расширенный функционал - пользовательская автоматизация (программирование) действий

[Евгений]

Не хотелось бы разводить дискуссии не по теме, но тем не менее спрошу. А может быть лучше вообще не заниматься учётом мышек и планочек? Я раньше тоже пытался вести инвентарный учёт всей мелочевки. Затраченные усилия и время очень велики и совершенно не оправдывают результата.

Вам ведь нужно оперировать крупными законченными единицами своей инфраструктуры, комплектами - "сервер", "рабочая станция" и т.д. Которые обладают определёнными характеристиками - ЖД 10 Тб (нормально, еще 2 месяца продержимся), ОЗУ 512 Гб (оп, уже упёрлись, тридцать восьмая виртуалка притормаживает, нужно докупать память). А какая там конкретно неонка внутре стоит, под каким инвентарным номером - это излишняя информация с переизбыточно высокой степенью детализации.

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

Зачем перегружать себя ненужной работой. Учёт ради учёта?

[dracul]

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

Сейчас у нас реализовано это путем добавления отдельной записи на каждую единицу комплектующих. Это удобно с точки зрения детализации информации. На каждый сервер также создается запись, а к ней привязываются все записи установленных в сервер комплектующих.
Зайдя в запись сервера мы видим все привязанные детали, то есть сразу видим всю конфигурацию сервера. У записей комплектующих есть текстовое поле, в котором обозначается сервер, в котором эта деталь в данный момент стоит. Это поле меняется через комментарии - таким образом мы сохраняем полную историю по каждой детали.
Описанная методика дает нам всю необходимую информацию. А также позволяет делать любые выборки, отчеты.

Есть несколько неудобств, которые я хотел бы устранить для уменьшения трудоемкости этого учета.

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

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

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

Решение тут напрашивается очевидное. Можно сделать возможность добавления нескольких дубликатов записи, в которых будут идентичными все поля, кроме указанных. И для этих полей задается сразу несколько значений, по одному на каждый дубликат. И система просто делает n циклов добавления записи, последовательно подставляя в изменяющееся поле следующее значение из указанных.

Я понимаю, что это довольно специфичные запросы.

[tommy.felt]

Смею предположить, что это станет юбилейной фичей в 2.0