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

Т.е. сейчас чтобы хотя бы создать таблицы, индексы и ограничения используются одинаковые команды для mysql и postgres? (Нет)

Выносить логику ПО на уровень БД — ерунда. Тем более, когда у тебя поддерживается множество бэкендов

посмотрите список официально поддерживаемых СУБД и давайте прекратим учить разработчиков, как им надо архитектурить ПО

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

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

Я про это знаю. Только я не вижу реального плюса от базовой поддержки 10 баз в случае Zabbix. Массово используют mysql и pg, остальное гораздо реже (личное мнение).

это личное мнение. на этом я закончил дискуссию. спасибо

Причем я про хранение конфигурации даже больше сейчас говорю. Исторические данные можно где-то ещё держать...

Скажи им, что это не пароль, а идентификатор.

Врать - это последнее к чему я бы пришёл при решении профессиональных задач.

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

Интересный философский момент, однако.

Вот, что нам говорит RFC1157, например: An SNMP message originated by an SNMP application entity that in fact  belongs to the SNMP community named by the community component of said message is called an authentic SNMP message.

Отсюда можно сделать вывод, что SNMP community string применяется для аутентификации. А процесс аутентификации не подразумевает обязательного применения пароля (предъявление пароля - только одна из разновидностей процедур аутентификации).

Поэтому, пока "безопасники" не выпустят положение о том, что SNMP community является паролем, я бы забивал на это дело. Но, впрочем, есть люди, которые бегут впереди паровоза и готовы сами себе устравивать проблемы там, где их ещё даже и нет ))

Это беда. Реальная

При включенном снмп, снмп комьюнити является секретом. Зная его, можно читать/писать настройки устройства

Если пароль не используется на фронтенде, то его там быть не должно совсем.

давайте я вам дам коммунити от своей ядерной железки... Прочитаете?

коммьюнити ещё и по сети открытым текстом шлют..

Наскоко я помню - комьюнити есть и RO. Так что необязательно, что "секрет" даёт право писать куда-то там.

Плохо помнишь