И таки никто так и не дошел до триггеров?

Смотри, пример из жизни. нужно зайти в комнату, пропылесосить, помыть полы, уйти из комнаты. У тебя это выглядит так. Работник заходит в дом и его замечает триггер. Пока работник поднимается по лестнице, триггер лезет в окно , пылесосит и убегает опять через окно. Работник заходит, опа, уже пропылесошено, осталось помыть полы. И все, блжет, работает. До тех пор, пока что то не изменили. И ВДРУГ стало непропылесошено. Кто, где когда пылесосил никто не знает, чртов триггер лазил через окно и его теперь никто не найдет.

Любой дурак может повесить триггер в конкретной базе данных. Нужен доступ и мануал. Но еще раз, триггеры - это последнее средство для стандартных мероприятий. Это внутренние дела базы данных, можно организовать логгирование, но никогда CRUD - операции

Хочешь - лепишь базу и по ней строишь код.
Но! При лепке кода из базы ограничений меньше.

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

Тебе что-то мешает реализовать сущность в виде таблицы?

Ничего. Кроме того, что сначала ты неделю программируешь базу данных. А потом я неделю набиваю по базе руками классы. А наоборот я набиваю классы(или строю УМЛ-диаграммы) и за 10 минут получаю готовую базу. Неделя экономии.

А потом я неделю набиваю по базе руками классы.

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

Любой дурак может повесить триггер в конкретной базе данных. Нужен доступ и мануал. Но еще раз, триггеры - это последнее средство для стандартных мероприятий. Это внутренние дела базы данных, можно организовать логгирование, но никогда CRUD - операции

В общем случае - нет. БД может использоваться как "связь" межу приложениями. Хоть это и не очень хорошо. И тогда триггер это самое простое и адекватное средство.

В примере с кофе - представьте что у нас одна база со счетами и бухгалтерией - таблицей, в которую записано сколько кофе каждого сорта продали, к которой лезут два приложения - официант и бухгалтер. Официанта интересуют только счета. Бухгалтера - только продажи. Кто из них должен лезть в чужие ентити? Бухгалтер в счета официанта или официант в бухотчетность? А почему бы через триггер в базе не увеличить счётчик проданного кофе?

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

Хибернейтом - геморройно. Что скорее говорит о качестве хибернейта. Ручками - без проблем.

А наоборот я набиваю классы(или строю УМЛ-диаграммы) и за 10 минут получаю готовую базу. Неделя экономии.

Ага. А потом три недели пытаемся оптимизировать запрос, для которого я пишу sql, отрабатывающий за 3 секунды, а хибернейт щелкает 3 часа если не вываливается с OutOfMemory. Получается проще 2 недели на базу и "ручной" доступ к ней потратить.

Надо сказать что я года с 2010 пытаюсь где только можно избегать хибернейта. Ну не работает такое общее решение в сложных приложениях. Его конфигурация становится чуть ли не самой сложной частью, которая ещё и с каждым bugfix-ом норовит сломаться. И в конце-концов всё равно пишем в самых критичных местах не hql а sql запросы. Ну и нафига тогда всё городить?

Но не всегда получается... Вот сейчас опять - нужна пакетная обработка порядка 10 миллионов записей. И всё написанное на хибернейте радостно хрюкает больше суток. Это уже знатоки хибернейта убили больше месяца на оптимизацию. Делаем триггер и вьюшку - опа, отрабатывает за 30 минут. Тоже плохо - часть бизнес-логики пришлось в бд пихать. Но уж лучше так.

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

Не могу. Представь, что что у тебя есть малознакомый человек. И тебе нужно отдать деньги. Вместо того, что бы просто отдать, ты заводишь с ним общий счет. Общий!!!! Это категорически неправильно. Каждое приложение должно быть изолировано и общаться с другими только через интерфейсы. И трижды должно быть изолировано хранилище данных.

Хибернейтом - геморройно. Что скорее говорит о качестве хибернейта. Ручками - без проблем.

Нет. Хайбернет это только стандарт де факто. Если можно без проблем стандартно, то нестандартно - это коствль. Ф топку

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

Это говорит о качестве модели. И о умении пользоваться персистентным слоем.

тоже плохо - часть бизнес-логики пришлось в бд пихать.

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

Я понимаю, что когда корабль тонет, нужно использовать то, что есть. И цеплятся за доски. Или если по другому НИКАК нельзя, то можно то, что нельзя. Но в нормальной стандартной проге нужно (имхо) использовать только стандартные решения. И неважно, что нестандартные быстрее, если скорость не критична. Легкость сопровождения важнее. Имхо

если скорость не критична

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

Помнится были и триггеры и stored procedure и materialized view.

Обращаем внимание на постскриптум

https://habr.com/ru/post/146717/

постскриптум в тему.

нужно зайти в комнату, пропылесосить, помыть полы, уйти из комнаты.

-----

нужно зайти в комнату, помыть полы, уйти из комнаты?

никто не знает

-----

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

Потому что лепка у тебя самодельная.

-----

Какая разница какая она у меня?

Ентити - стандарт для .Нет и там ДВА варианта.

Кроме того, что сначала ты неделю программируешь базу данных.

-----

Ээээ???

Вообще-то, это на уровне подготовительной группы детского садика.

Если мне удобно - а иногда мне удобнее конвертировать документацию в скрипты - делаю скрипты. Да - руками, да - долго. Но обычно все же быстрее чем даже построение УМЛ.

Если мне не удобны скрипты - пользую любой редактор с визуальным представлением - хоть ЭМ, хоть Деварт, хоть... Аксесс...

А потом я неделю набиваю по базе руками классы.

-----

Ну это твое дело - хочешь руками - делай руками.

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

А наоборот я набиваю классы(или строю УМЛ-диаграммы) и за 10 минут получаю готовую базу.

-----

Ну и как ты туда триггер запихиваешь?

Попробую так.

Задачка из топика.

База - полностью, т.е. в 5-ю форму, нормализованная.

Что ты будешь делать чтобы собрать исходную таблицу?

Будешь утверждать что не надо 5-ю форму?

Или попросишь несколько вьюшек слепить?

А инструмент для вьюшек у тебя есть?

А если вьюшек не хватит и процедура потребуется?

Упсс - опять уперлись в инструменt...

Знакомый в Уни, начал подкидывать задачки.

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

Алгоритм может быть таким:

-1- включить зелёный машинам, пешеходам красный

-2- если пешеход нажал кнопку, и машинам зелёный горел уже достаточно долго

- включить машинам желтый

- чуть подождать

- включить машинам красный

- чуть подождать

- включить пешеходам зелёный

- выдержать достаточно времени для хождения пешеходов

- включить пешеходам красный, а машинам желтый

- чуть подождать

- включить машинам зеленый

- перейти к -2-

........

R,Y,G - лампочки светофора машинам

R2,G2 - лампочки светофора пешеходам

Алгоритм может быть таким

-----

Не может.

В алгоритмах УПРАВЛЕНИЯ вообще не может быть никакой прописанной логики. Тем более логики, в которой принимаемое решение зависит от того какой кусок кода выполнялся на предыдущем шаге.

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

Только тогда это работает.

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

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

В алгоритмах УПРАВЛЕНИЯ вообще не может быть никакой прописанной логики. Тем более логики, в которой принимаемое решение зависит от того какой кусок кода выполнялся на предыдущем шаге. В таких алгоритмах выделяется то что называется "текущее состояние" и на его базе строится обычный цифровой автомат.

Кстати на картинке изображен именно цифровой автомат (State Maschine). Точнее два.

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

на картинке изображен именно цифровой автомат

-----

Увы, но нет...

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

Функция перехода должна изменить (атомарная операция) текущее состояние.

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

Как следствие - код автомата никак не должен зависеть от конфигурации перекрестка и выбранного режима работы светофоров - автомат будет один и тот же.

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

не требует никак обрабатывать эту ситуацию

-----

В Риге тоже не обрабатывали - два поезда столкнулись и появилась куча трупов...

П.С. Что данное решение не для осваивающих иф-елсе-тхен - Я вполне понимаю.

В Риге тоже не обрабатывали - два поезда столкнулись и появилась куча трупов...

Что данное решение не для осваивающих иф-елсе-тхен - Я вполне понимаю.

росто потому что после выполнения очередного шага автомат должен перейти из состояния А в состояние Б и находится в положении которое было до начала перехода из А в Б, за исключением измененного "текущего состояния". Функция перехода должна изменить (атомарная операция) текущее состояние.

Код автомата должен никак не зависеть от того из какого и в какое состояние автомат переключается.

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

конечно специальные языки ее упрощают

Для этого нужно знать эти специальные языки и упрощение тоже еще вопрос.

Но перед алгоритмом нужно хоть немного описать задачу.

Похоже у нас есть два светофора стоящих на пешеходном переходе: один для машин, другой для пешеходов. Имеется еще кнопка запроса перехода.

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

Для этого нужно знать эти специальные языки и упрощение тоже еще вопрос.

Этот что на картинке подобен стандартному SFC.

https://ftp.owen.ru/CoDeSys3/98_Books/plcopen_sfc_v10_ru.p...

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

На текстовом языке, а ля C# или стандартном ST (а также на графических стандартных FBD, LD) этот алгоритм будет выглядеть гораздо менее привлекательным.

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

Нужно еще определится с алгоритмом запроса пешехода на переход.

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

https://m.habr.com/ru/post/254885/

Если выходной сигнал цифрового автомата зависит лишь от текущего состояния, то такой автомат называется автоматом Мура

😁

подкидывать задачки.

Вот реальная задача управления светом в подвале школы (как то товарищ попросил запрограммировать с его слов)

- есть кнопка.

- начальное состояние - выключить свет (если включен).

- при нажатии кнопки включить свет.

- если кнопка нажата коротко, то свет сам потом выключается через некоторое время. (далее начальное состояние)

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

- если кнопку нажать очень долго (более 10 секунд), то свет моргает один раз (т.е. тухнет на 1 секунду и опять включается) и устанавливается некий сигнал (зачем нужен не знаю).

- после этого короткие нажатия кнопки игнорируются, а при долгом нажатии (10секунд), свет моргает 5 раз и тухнет, а некий сигнал сбрасывается через некоторое время начиная с начала 5тикратного моргания. (далее начальное состояние).

...

Кроме того есть аварийный сигнал.

Если он пришел, свет включается, некий сигнал выключается, а вышеприведённый алгоритм отключается не зависимо от текущего его шага.

Когда аварийный сигнал уйдёт, то алгоритм стартует с начального состояния.

всё это соблюдено в диаграмме выше.

----

Увы-увы, но нету там этого.

Например, у тебя там НЕТ возможности переключить все светофоры перекрестка в "Мигающий Желтый".

А когда ты это попытаешься добавить - у тебя появится довольно неприятное усложнение логики.

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

А усложнения недолжно быть - функция автомата не поменялась - автомат должен управлять включением/выключением ламп светофора. И только.

Ибо именно код автомата определяет из какого состояния и в какое и при каких условиях автомат переключается.

-----

Это на самом деле - просто.

С - состояние

У - управляющее воздействие

Тогда автомат А определяется как

С = А(С,У).

Если У - пустое - нет кнопок или удаленного управления - будет С = А(С) или С = А(С,нулл)

А автомат переключается в любом случае - даже в том, когда С(до) тождественно равно С(после)

ввиду упрощенной задачи), ибо нет

-----

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

Но в сколь-нибудь реальном управлении так работать не будет. Нее - воткнуть - можно, но будут проблемы.

Грубо говоря - в реальной системе ты должен взять текущее С (например состояние ламп включено/выключено/перегорела плюс "режим работы") и текущее У (например, кнопки, таймер, ошибки) рассчитать новое С. На каждом шаге т.е. изменении состояния ламп - все пересчитываешь из лампы+ и все У... Дрючить "кодом автомата" какую-то одну лампу/кнопку/таймер - нельзя.

Тогда - будет работать.

Т.е. активация очередного состояния является следствием предыдущего и условия перехода.

-----

Тут ты упускаешь что после смены состояния (переключения ламп) автомат должен находится в позиции "готовность к очередному изменению состояния" и что это всегда одна и та же позиция.

если задача является последовательностью (во времени) шагов

-----

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

Попробуй - тебе понравится.

не должно быть никакой "последовательности"

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

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

ввиду упрощенной задачи), ибо нет ----- Ты просто частью отбросил, частью замаскировал...