А вот управляющую обмотку контактора было не обязательно брать на 12В, можно было легко взять на 220 и питать ее через промежуточное реле
При размыкании всё происходит в обратном порядке: сперва размыкается электромагитное реле и ток подхватывает на десяток миллисекунд твердотельное. Когда контакты электромагнитного разъехались достаточно далеко, отключает линию и твердотельное реле.
А смысл объединять две противоположные по принципу работы и характеристикам вещи в одной?
Одному надо переключение через 10 сек, другому только при включенной усл. "Кнопка 2".
Ну и абсолютно различные условия наработки на отказ: механическое может выпилится после определенного кол-ва срабатываний, а электронное наоборот после превышения токов/напряжения.
Мне приходилось иметь дело с БД ВУЗа на несколько гигов размеров и в ней на полторы тысячи таблиц было более полутора тысяч хранимых процедур с кучей логики. Да, это было давно, но какой же это был ад!
Я имел в виду, что трггеры, особенно триггеры с тяжелыми проверками, влияют на производительность. Триггер срабатывает на изменение всей заиси, а факт изменения отдельных полей нужно детектить внутри триггера. Но мы же можем захотитеть делать более сложные валидации внутри БД, и нам для этого захоется внутри триггера делать SQL-запросы, обращаться к каким-то внешним настройкам, а эти настройки могут вдруг поменяться...
Валидация слишком расплывчатое понятие. Может быть валидация простых вещей вроде гендера ещё норм и куда ни шло, внешние ключи- тоже приемлемо, а вот валидация номера телефона по регекспу или email - это уже ближе к тому, о чем я говорил.
А ещё мы можем захотеть детектить на уровне БД наличие похожих по написанию букв на разных языках. К примеру, русская фамилия с английской буквы "A" будет ломать сортировку, а выглядеть корректно. Место ли для такой валидации на уровне БД? А проверка адекватности даты рождения?
Я лишь хотел сказать, что эту черту приемлемости размещения тех или иных валидаций в БД проводят по-разному.
Если мы говорим о том. что у нас большой проект и много неопытных чижиков без налаженного ревью кода, то косяк в валидации ввода на бэке попортит новые записи, а косяк в изменении правил валидации на уровне БД может обрушить всю базу.
Я писал про тяжелые нетривиальные валидации.
Да уступает. Резльтат валидации на уровне бэка обрабатывается ближе к точке, где что-то можно исправить, а валидация глубоко в БД требует нетривиального подъёма ошибки в бэк и обработки её на разных уровнях: бд, бэк, фронт. Больше ступеней.
Я не утверждаю. что нельзя сделать правильнее, но в большинстве случаев валидации на бэке удобнее, понятнее и проще.
Опять же, это сильное утверждение, а реальные проекты обычно достаточно сложны, чтобы такие сильные утверждения не обрастали нюансами.
Я имел в виду, что код, касающийся одной и той же валидации будет размещен и в триггере внутри БД, и в соответствующей миграции (или в сложных случаях в цепочке миграций), и в бэкенде а уровне бизнес-логики, и в бэкенде на уровне хендлеров АПИ, и во фронтенде для пояснения пользователю что не так и для предупреждения возможных ошибок при вводе.
Я конечно сгущаю краски немного, но если некоторые валидации делать не в БД, то эта лестница будет на ступеньку меньше.
Да, речь не о констрейнах, которые уже привнесли непростую концепцию лукап полей. Эта штука у нас трогает и фронт и бэк, а ошибки нужно правильно эскалировать и в нужном месте обрабатывать. И снова вопрос где провести черту.
Мне кажется мы говорим каждый о своей крайности и на конкретных примерах вряд ли бы не согласились друг с другом.
Я считаю, что ограничивать выбор пола на уровне БД при остутствии словарной таблицы - с порно.
"БД как бастион" - это не близкая мне концепция. Я склоняюсь к простоте, всяким NoSQL, и чтоб не упарываться сильно с нормализацией данных без острой на то нужды и необходимости.
Оверинженеринг там, где в нем нет острой необходимости плох.