Когда один вместо бд использует простенький одностраничный xml, попробовать, вроде работает и далее файлы плодятся десятками, некоторые достигают размеров сотен страниц. Вся эта прелесть преподносится как среда разработки для низкоуровневых программеров приборов, которые должны эту технологию использовать, если заменили прошивку или не дай бог сделали новый девайс с сотней другой регистров. В конечном итоге все это длится несколько лет и автор этой хрени сваливает в другую контору, руководство задает тебе вопрос, а как сделать более человеческий интерфейс без этой ужасной возни с огромными xml файлами, ибо это очень неудобно, хоть и работает. А никак, отвечаешь. Надо переписывать с нуля, потому что там костылей немеряно. И проблема даже не в этом , а в том как перенести из файлов xml не потряв связность дерево объектов в БД. В файлах давно сам черт ногу сломит что наворотили, смешав в кучу регистры и указатели на кнопки комбобоксы интерфейса. Естественно разбираться с этим говнокодом не стали. Просто написали с нуля. Перенос файлов был сделан в SQL и это было непросто. Можно отдельную статью написать.
Технологии ИИ конечно развиваются, но решения все равно принимает человек и ответственность тоже лежит на человеке, а не на инструменте, чем по сути является ИИ. Сейчас это в общем сильно похоже на пузырь, с расчетом на определенные отрасли, где ответственность не так сильно важна, например программирование web и тп,. Но никто не будет ломать существующие технологии разработки полностью под ии, люди нужны для контроля и ответственности и сильно возрастает важность квалификации программиста, использующего ИИ в качестве инструмента. И это в любой отрасли, где возможно применение технологий нейросетей и LLM. Думается массовое выключение людей из сфер деятельности и замена на ии невозможна в принципе не только по соображениям ответственности, но и по соображениям обычной логики превращения людей в придаток компьютерных моделей.
Delphi применяю до сих пор. Первый раз это было в 1999, когда создал в связке с. SQL SERVER систему с CRM и много еще чего. Снабжение, сбыт, интерфейс с 1С бухгалтерией. Все это прожило 10 лет и умерло просто потому что захотелось конторе перейти на 1с, да и мне поддержка уже надоела старой системы, так как перешел от разработки программ к разработке электроники. Сейчас это вернулось, так как разработка электроники требует разработки программ тестирования и т п. Ничего лучше и удобней Delphi с такими задачами просто нет. Интерфейс делается быстро, все зависимости в БД.
Одно время пользовался MERGE, но отказался из- за того что порой не работало. Не стал разбираться. Лучше в сложной транзакции использовать обычные запросы или UPDATE....F ROM в хранимых процедурах. Это проще и контролировать и тестировать.
Мне скоро 65 и SQL я знаю так, что все мои разработки основаны на нем, родимом. В статье в профиле я описал одну из своих разработок. Наверно мне повезло, я вернулся в разработку в 58, так сложились обстоятельства в работе. В той области специфической , где я работаю найти готового спеца было сложно. Если хочешь сделать хорошо, сделай сам.Я смотрю на молодых, которые вынуждены подстраиваться под современные реалии web и вижу что многие знают всего понемножку, но ничего хорошо не знают. Тут немного, там немного и еще все это глючит и тяжелое. Да еще частое использование ИИ отучает от самостоятельного мышления. Если так пойдет дальше то можно выразится словами классика- грядущее их пусто и темно. Не webом единым живо программирование. Огромный пласт в корпоративном секторе средних компаний живет только с 1с и excel. И не только в офисе но и в производстве нужны программы, которые не напишешь в 1c из за специфики работы и наличия квалификации программистов.
Поиграются с ИИ какое -то время, потом поймут что без человека соответствующей квалификации это все не работает. К тому же ИИ не накажешь за ошибки, дыры в безопасности и т д и т п. Получишь кучу кода и кто все это будет контролировать? Людей потребуется больше и квалификации выше. Веб -это только вершина айсберга. А под водой огромные и сложные области программирования намного больше чем WEB и ресурсов на это тоже требуется много и высококвалифицированных. ИИ туда не прикрутишь из-за специфики и опять же необходимости контроля со стороны квалифицированного программиста.
Вопрос интересный про параллелизм и асинхронность. Просто надо учитывать некоторые вещи а именно, доступ к ресурсу. А доступ к нему , например к БД идет через тот же Ethernet,, это не параллельный доступ к сети а случайный. Задержка будет зависеть от количества пакетов на линии. Далее сам ceрвер данных , транзакционая модель которого тоже не дает параллельного доступа к ресурсу ( очередь, по аналогии со статьей причем жесткая и если несколько покупателей пытаются вырвать ресурс-колбасу из рук продавца-сервера, то тот сам решает кому ее отдать, так разруливая дедлок. Нас спасает только размазывание запросов во времени. Про параллелизм здесь можно забыть от слова совсем. В жизни параллелизм вполне возможен. Я ставлю чайник и пока он закипает делаю 50 отжиманий, к примеру.
Я использую функциональную и реляционную с бизнес-логикой в реляционной. И кто бы там что не говорил про эту модель, она очень даже хороша в той области где я работаю. Другие варианты намного сложнее было бы применять, если бизнес логику переносить в функциональную часть и использовать реляционную просто как хранилище.
Полностью согласен с вами. Насчет опыта программирования и следованию паттернам. Мне один уже уволившийся из фирмы программер сказал что он не использует встроенные процедуры в БД, указав на книги в которых везде написано что это неправильный подход. Но он написал важную для фирмы программу вообще без бд, используя в ее качестве xml файлы. Это был его "паттерн". В результате это привело к тому что пользователи вынуждены создавать и редактировать такие файлы и некоторые из них по сотне страниц. Вы пробовали когда-нибудь заменять куски xml в файле такого обьемa? Ему просто надо было создавать нормальное приложение с БД и редактором, но ведь можно использовать пользователей и не напрягаться в этом плане. В результате мне пришлось все эти xml перетаскивать в БД, а пользователи уже насоздавали новых с перемешанными атрибутами дерева объектов. В результате пришлось разработать метод импорта в БД в самой БД через сложные встроенные процедуры и переписывать всю программу с нуля с редактором дерева обьектов и новой парадигмой разделения на рабочие и тестовые конфигурации приборов одновременно для сетевого и локального варианта. Перенос из хмл в БД это была очень нетривиальная задача, так как следовало сохранить дерево и связи в таблицах бд.
Вместо того чтобы потратить время на тренировку на отсутствие зевков, время потрачено на создание бота для читеров. Зевают все в блице. Иногда при игре чувствуешь как соперник просто не ошибается и очень мощно зажимает, но рейтинг как у тебя. Наверно поэтому на турнирах личесс пишут что боты не допускаются. Вообще цели создания подсказывающего бота непонятны. Это просто говорит о том что сам без бота ты не способен поднять свой рейтинг. Лично мне рейтинг особо не нужен, так как играю для удовольствия и гимнастики ума, иногда просто чтобы убить время ожидания.
Делайте как вам удобно. Я в основном использую sql и delphi. Эта мощная двухзвенка закрывает все мои рабочие задачи без всяких web интерфейсов и прочей модной шелухи. Просто и быстро. Это главное.
ООП это не панацея в программировании и в большинстве задач оно не нужно, то есть мышление объектами и их программированием. Все это реклама и мода. Не более.
Нейронка и человек это принципиально разные системы. Человек обладает эмоциями, нейронка это просто вычислитель с перемножением матриц. Человекоподобие в рассуждениях ей создают искуственно через некие паттерны программирования. Человек же познает новое и двигается в новое и неизведанное только благодаря своему эмоциональному центру. У нейронок этого нет и не будет никогда. Они лишь инструменты и инструментами и останутся. Для кого-то это инструмент зарабатывания денег, для других - типа "двое из ларца" . И это в общем их предел.
Когда в юности я начал играть на гитаре, то гитарная музыка для меня была чем-то недосягаемым, но манила и притягивала как магнит. Игра какой- нибудь классической пьесы казалась магией. Книги и самоучители не могли дать мне такие возможности, которые нужны были для игры и не бренчания. В те далекие времена не было интернета, ютуба и пр. Прошло много много лет. И вот однажды я случайно познакомился с человеком, который прекрасно играл, профессионалом своего дела, закончившим консерваторию по классу гитары. Общение с ним было очень полезным. Он не учил играть, он рассказывал и показывал тонкости владения гитарой как музыкальным инструментом. Ну и появление интернета, ютуба позволило с учетом имеющихся базовых знаний и навыков понять что нужна и нотная грамота для того чтобы даже не играть с листа, а просто разобрать то что хочешь играть. Я всю жизнь мечтал играть классику, но с появлением интернета мир гитары расширилнся для меня и для джаза, фингерстайла и пр. Я мечтал играть Баха, теперь, после многих усилий и знаний я его играю, это казалось невероятно сложным, но главное иметь желание, немного таланта , много труда и это становится возможным. В свое время меня поразил Томми Эммануэль своей невероятной гитарной музыкой. И вот я играю уже его старые и красивые композиции. Это гораздо легче чем играть Баха, но удовольствия не меньше доставляет. И так со многими пьесами, которые выучил. Есть и несколько , которые сам написал. Чем больше кругозор и навыков, тем больше приходит в голову идей и ты в состоянии их развить р превратить в музыку. Главное это ваши желания и настойчивость. Не стоит посвящать этому всю свою жизнь если у вас нет особого таланта музыканта. Но если есть желание идти смузыкой по жизни то это зависит только от вашего желания.
Я еще не написал про легкую поддержку транзакций в хранимых процедурах. Я использую не только хранимыее процедуры, но и функции в sql, последовательности, сте в хранимках, сложную фильтрацию через входные параметры. Специальный триггер в БД следит за dml кодом хранимов и регистрирует все операции dml, вся история dml и код хранимок пишутся в отдельную таблицу специальной БД. Любая компиляция процедуры или функции заносит новую версию в таблицу. Ее можно посмотреть, и откатить при необходимости. Такой своеобразный git. Ну и использовать sql ин'eкции в такой архитектуре практически невозможно. Я уж не говорю про динамический sql.
Для меня SQL более удобный язык чем язык клиента для бизнес логики. В БД свобода, а на клиенте вы вынуждены применять всякие костыли в виде сложения строк запросов, проблемы с отладкой, интерфейсные зависимости переплетаются с логикой бизнес процессов,нет возможности полноценно отлаживать запросы, их оптимизировать по скорости, вся эта лапша с интерфейсом и бизнес логикой и т д и тп. Те кто использует орм все равно вынуждены проверять как работает запрос напрямую на сервере sql, так как нет гарантии что орм правильно работает, особенно в сложных приложениях если есть проблемы. Правильная архитектура приложения, разбиение бизнес процессов на операции, логирование операций, дает возможность избавится от обектно ориентированной логики на клиенте и писать в обычном функциональном стиле с обработкой интерфейсных событий через встроенные процедуры. Другое дело если вы не умеете так строить приложения в БД . в такой двухзвенной архитектуре я еще двадцать пять лет назад написал свою erp c систему в которой были сервисы CRM, заказы, снабжение и комплектация заказов с приоритетами, отгрузка заказов, склад, формирование документов, экспорт данных в 1С бухгалтерию, хранилище файлов в БД по типу файловой системы, поддержка документооборота в хранилище. Система прожила 10 лет у заказчика, пока я ее поддерживал. И это все прекрасно работало на Windows ХР и среднем сервере в то время .
Я триггеры практически не использую сознательно. Очень редко в единичных случаях. Насчет обновления приложения у меня так- ехе лежит в сетевой папке, у пользователя ярлык на рабочем столе . если надо обновить, то файл переименовываю и записываю новый exe . в одном приложении даже сделал меssenger в бд через который всем посылаю сообщение что программа обновлена и ее надо перезапустить. Вот и все обновление. Если программа запущена, то сообщение открывается в модальном окне и его невозможно пропустить не прочитав. Все приложения мои логируются и все что делал пользователь я вижу в этой же программе, в том числе прочитал ли он сообщение. Это возможно потому что каждое приложение имеет такую архитектуру, где предусмотрена таблица коннектов, таблица логов, таблица справочника операций. Это кстати упрощает разработку бизнес логики в БД. Общая система мониторинга всех приложений позволяет видеть все запущенные приложения и пользователей и их логи операций. Все ходы записаны, легко разобраться кто когда и что делал. В одном приложении у меня 75 пользователей из разных отделов компании, через которые проходит документ и если нужны разборки то логи все показывают.
Ну а смысл этой трехзавенки тогда, если она усложняет разработку? Я сторонник минимализма , если задача позволяет. Зачем делать сложно когда можно сделать проще, быстрее и меньшим составом разработчиков? У меня команда это два человека. А задачи непростые. Это как говорят не "джесоны перекладывать". Delphi меня вполне устраивает, и все приятные мелочи, которые можно одной строчкой реализовать, к примеру переключится автоматом на русский язык если курсор в поле ввода. Попробуйте это сделать на любом другом языке кроме С. Мода на web интерфейс только усложняет и удлиняет разработку и ничего не дает в общем. Delphi ceйчас в общем это не совсем тот Delphi, который был 20 лет назад, Теперь можно писать под все платформы. Появились и динамические массивы к примеру, чего в старых вариантах Delphi не было. Драйверы под любую БД есть. Даже для sqlite имеется драйвер.
Логика в БД, идентификация на сервере и настройки прав доступа по ролям в БД. Это то что я использую в разработке на чистом SQL. В качестве клиента есть и nocode (LabVIEW) и Delphi последней версии. Системы сложные. Однa из них описана в моей статье в хабр профиле. Даже мысли нe было использовать костыли вместо нативного SQL. Ну и оптимизация sql по скорости это наше все. Процедуры и функции sql более эффективны и упрощают разработку сложных приложений. К сожалению это понимает не каждый. У меня количество пользователей не миллионы, но задачи компенсируются значительной сложностью бизнес процессов. Поэтому логика в БД позволяет не только разрабатывать , но и относительно просто сопровождать и дорабатывать приложения при необходимости не ломая главного- бизнес модели.
Когда один вместо бд использует простенький одностраничный xml, попробовать, вроде работает и далее файлы плодятся десятками, некоторые достигают размеров сотен страниц. Вся эта прелесть преподносится как среда разработки для низкоуровневых программеров приборов, которые должны эту технологию использовать, если заменили прошивку или не дай бог сделали новый девайс с сотней другой регистров. В конечном итоге все это длится несколько лет и автор этой хрени сваливает в другую контору, руководство задает тебе вопрос, а как сделать более человеческий интерфейс без этой ужасной возни с огромными xml файлами, ибо это очень неудобно, хоть и работает. А никак, отвечаешь. Надо переписывать с нуля, потому что там костылей немеряно. И проблема даже не в этом , а в том как перенести из файлов xml не потряв связность дерево объектов в БД. В файлах давно сам черт ногу сломит что наворотили, смешав в кучу регистры и указатели на кнопки комбобоксы интерфейса. Естественно разбираться с этим говнокодом не стали. Просто написали с нуля. Перенос файлов был сделан в SQL и это было непросто. Можно отдельную статью написать.
Технологии ИИ конечно развиваются, но решения все равно принимает человек и ответственность тоже лежит на человеке, а не на инструменте, чем по сути является ИИ. Сейчас это в общем сильно похоже на пузырь, с расчетом на определенные отрасли, где ответственность не так сильно важна, например программирование web и тп,. Но никто не будет ломать существующие технологии разработки полностью под ии, люди нужны для контроля и ответственности и сильно возрастает важность квалификации программиста, использующего ИИ в качестве инструмента. И это в любой отрасли, где возможно применение технологий нейросетей и LLM. Думается массовое выключение людей из сфер деятельности и замена на ии невозможна в принципе не только по соображениям ответственности, но и по соображениям обычной логики превращения людей в придаток компьютерных моделей.
Delphi применяю до сих пор. Первый раз это было в 1999, когда создал в связке с. SQL SERVER систему с CRM и много еще чего. Снабжение, сбыт, интерфейс с 1С бухгалтерией. Все это прожило 10 лет и умерло просто потому что захотелось конторе перейти на 1с, да и мне поддержка уже надоела старой системы, так как перешел от разработки программ к разработке электроники. Сейчас это вернулось, так как разработка электроники требует разработки программ тестирования и т п. Ничего лучше и удобней Delphi с такими задачами просто нет. Интерфейс делается быстро, все зависимости в БД.
Одно время пользовался MERGE, но отказался из- за того что порой не работало. Не стал разбираться. Лучше в сложной транзакции использовать обычные запросы или UPDATE....F ROM в хранимых процедурах. Это проще и контролировать и тестировать.
65 скоро и работаю по факту программистом. Не каждый молодой и даже не очень способен строить сложные программные системы.
Мне скоро 65 и SQL я знаю так, что все мои разработки основаны на нем, родимом. В статье в профиле я описал одну из своих разработок. Наверно мне повезло, я вернулся в разработку в 58, так сложились обстоятельства в работе. В той области специфической , где я работаю найти готового спеца было сложно. Если хочешь сделать хорошо, сделай сам.Я смотрю на молодых, которые вынуждены подстраиваться под современные реалии web и вижу что многие знают всего понемножку, но ничего хорошо не знают. Тут немного, там немного и еще все это глючит и тяжелое. Да еще частое использование ИИ отучает от самостоятельного мышления. Если так пойдет дальше то можно выразится словами классика- грядущее их пусто и темно. Не webом единым живо программирование. Огромный пласт в корпоративном секторе средних компаний живет только с 1с и excel. И не только в офисе но и в производстве нужны программы, которые не напишешь в 1c из за специфики работы и наличия квалификации программистов.
Поиграются с ИИ какое -то время, потом поймут что без человека соответствующей квалификации это все не работает. К тому же ИИ не накажешь за ошибки, дыры в безопасности и т д и т п. Получишь кучу кода и кто все это будет контролировать? Людей потребуется больше и квалификации выше. Веб -это только вершина айсберга. А под водой огромные и сложные области программирования намного больше чем WEB и ресурсов на это тоже требуется много и высококвалифицированных. ИИ туда не прикрутишь из-за специфики и опять же необходимости контроля со стороны квалифицированного программиста.
Вопрос интересный про параллелизм и асинхронность. Просто надо учитывать некоторые вещи а именно, доступ к ресурсу. А доступ к нему , например к БД идет через тот же Ethernet,, это не параллельный доступ к сети а случайный. Задержка будет зависеть от количества пакетов на линии. Далее сам ceрвер данных , транзакционая модель которого тоже не дает параллельного доступа к ресурсу ( очередь, по аналогии со статьей причем жесткая и если несколько покупателей пытаются вырвать ресурс-колбасу из рук продавца-сервера, то тот сам решает кому ее отдать, так разруливая дедлок. Нас спасает только размазывание запросов во времени. Про параллелизм здесь можно забыть от слова совсем. В жизни параллелизм вполне возможен. Я ставлю чайник и пока он закипает делаю 50 отжиманий, к примеру.
Я использую функциональную и реляционную с бизнес-логикой в реляционной. И кто бы там что не говорил про эту модель, она очень даже хороша в той области где я работаю. Другие варианты намного сложнее было бы применять, если бизнес логику переносить в функциональную часть и использовать реляционную просто как хранилище.
Полностью согласен с вами. Насчет опыта программирования и следованию паттернам. Мне один уже уволившийся из фирмы программер сказал что он не использует встроенные процедуры в БД, указав на книги в которых везде написано что это неправильный подход. Но он написал важную для фирмы программу вообще без бд, используя в ее качестве xml файлы. Это был его "паттерн". В результате это привело к тому что пользователи вынуждены создавать и редактировать такие файлы и некоторые из них по сотне страниц. Вы пробовали когда-нибудь заменять куски xml в файле такого обьемa? Ему просто надо было создавать нормальное приложение с БД и редактором, но ведь можно использовать пользователей и не напрягаться в этом плане. В результате мне пришлось все эти xml перетаскивать в БД, а пользователи уже насоздавали новых с перемешанными атрибутами дерева объектов. В результате пришлось разработать метод импорта в БД в самой БД через сложные встроенные процедуры и переписывать всю программу с нуля с редактором дерева обьектов и новой парадигмой разделения на рабочие и тестовые конфигурации приборов одновременно для сетевого и локального варианта. Перенос из хмл в БД это была очень нетривиальная задача, так как следовало сохранить дерево и связи в таблицах бд.
Вместо того чтобы потратить время на тренировку на отсутствие зевков, время потрачено на создание бота для читеров. Зевают все в блице. Иногда при игре чувствуешь как соперник просто не ошибается и очень мощно зажимает, но рейтинг как у тебя. Наверно поэтому на турнирах личесс пишут что боты не допускаются. Вообще цели создания подсказывающего бота непонятны. Это просто говорит о том что сам без бота ты не способен поднять свой рейтинг. Лично мне рейтинг особо не нужен, так как играю для удовольствия и гимнастики ума, иногда просто чтобы убить время ожидания.
Делайте как вам удобно. Я в основном использую sql и delphi. Эта мощная двухзвенка закрывает все мои рабочие задачи без всяких web интерфейсов и прочей модной шелухи. Просто и быстро. Это главное.
ООП это не панацея в программировании и в большинстве задач оно не нужно, то есть мышление объектами и их программированием. Все это реклама и мода. Не более.
Нейронка и человек это принципиально разные системы. Человек обладает эмоциями, нейронка это просто вычислитель с перемножением матриц. Человекоподобие в рассуждениях ей создают искуственно через некие паттерны программирования. Человек же познает новое и двигается в новое и неизведанное только благодаря своему эмоциональному центру. У нейронок этого нет и не будет никогда. Они лишь инструменты и инструментами и останутся. Для кого-то это инструмент зарабатывания денег, для других - типа "двое из ларца" . И это в общем их предел.
Когда в юности я начал играть на гитаре, то гитарная музыка для меня была чем-то недосягаемым, но манила и притягивала как магнит. Игра какой- нибудь классической пьесы казалась магией. Книги и самоучители не могли дать мне такие возможности, которые нужны были для игры и не бренчания. В те далекие времена не было интернета, ютуба и пр. Прошло много много лет. И вот однажды я случайно познакомился с человеком, который прекрасно играл, профессионалом своего дела, закончившим консерваторию по классу гитары. Общение с ним было очень полезным. Он не учил играть, он рассказывал и показывал тонкости владения гитарой как музыкальным инструментом. Ну и появление интернета, ютуба позволило с учетом имеющихся базовых знаний и навыков понять что нужна и нотная грамота для того чтобы даже не играть с листа, а просто разобрать то что хочешь играть. Я всю жизнь мечтал играть классику, но с появлением интернета мир гитары расширилнся для меня и для джаза, фингерстайла и пр. Я мечтал играть Баха, теперь, после многих усилий и знаний я его играю, это казалось невероятно сложным, но главное иметь желание, немного таланта , много труда и это становится возможным. В свое время меня поразил Томми Эммануэль своей невероятной гитарной музыкой. И вот я играю уже его старые и красивые композиции. Это гораздо легче чем играть Баха, но удовольствия не меньше доставляет. И так со многими пьесами, которые выучил. Есть и несколько , которые сам написал. Чем больше кругозор и навыков, тем больше приходит в голову идей и ты в состоянии их развить р превратить в музыку. Главное это ваши желания и настойчивость. Не стоит посвящать этому всю свою жизнь если у вас нет особого таланта музыканта. Но если есть желание идти смузыкой по жизни то это зависит только от вашего желания.
Я еще не написал про легкую поддержку транзакций в хранимых процедурах. Я использую не только хранимыее процедуры, но и функции в sql, последовательности, сте в хранимках, сложную фильтрацию через входные параметры. Специальный триггер в БД следит за dml кодом хранимов и регистрирует все операции dml, вся история dml и код хранимок пишутся в отдельную таблицу специальной БД. Любая компиляция процедуры или функции заносит новую версию в таблицу. Ее можно посмотреть, и откатить при необходимости. Такой своеобразный git. Ну и использовать sql ин'eкции в такой архитектуре практически невозможно. Я уж не говорю про динамический sql.
Для меня SQL более удобный язык чем язык клиента для бизнес логики. В БД свобода, а на клиенте вы вынуждены применять всякие костыли в виде сложения строк запросов, проблемы с отладкой, интерфейсные зависимости переплетаются с логикой бизнес процессов,нет возможности полноценно отлаживать запросы, их оптимизировать по скорости, вся эта лапша с интерфейсом и бизнес логикой и т д и тп. Те кто использует орм все равно вынуждены проверять как работает запрос напрямую на сервере sql, так как нет гарантии что орм правильно работает, особенно в сложных приложениях если есть проблемы. Правильная архитектура приложения, разбиение бизнес процессов на операции, логирование операций, дает возможность избавится от обектно ориентированной логики на клиенте и писать в обычном функциональном стиле с обработкой интерфейсных событий через встроенные процедуры. Другое дело если вы не умеете так строить приложения в БД . в такой двухзвенной архитектуре я еще двадцать пять лет назад написал свою erp c систему в которой были сервисы CRM, заказы, снабжение и комплектация заказов с приоритетами, отгрузка заказов, склад, формирование документов, экспорт данных в 1С бухгалтерию, хранилище файлов в БД по типу файловой системы, поддержка документооборота в хранилище. Система прожила 10 лет у заказчика, пока я ее поддерживал. И это все прекрасно работало на Windows ХР и среднем сервере в то время .
Я триггеры практически не использую сознательно. Очень редко в единичных случаях. Насчет обновления приложения у меня так- ехе лежит в сетевой папке, у пользователя ярлык на рабочем столе . если надо обновить, то файл переименовываю и записываю новый exe . в одном приложении даже сделал меssenger в бд через который всем посылаю сообщение что программа обновлена и ее надо перезапустить. Вот и все обновление. Если программа запущена, то сообщение открывается в модальном окне и его невозможно пропустить не прочитав. Все приложения мои логируются и все что делал пользователь я вижу в этой же программе, в том числе прочитал ли он сообщение. Это возможно потому что каждое приложение имеет такую архитектуру, где предусмотрена таблица коннектов, таблица логов, таблица справочника операций. Это кстати упрощает разработку бизнес логики в БД. Общая система мониторинга всех приложений позволяет видеть все запущенные приложения и пользователей и их логи операций. Все ходы записаны, легко разобраться кто когда и что делал. В одном приложении у меня 75 пользователей из разных отделов компании, через которые проходит документ и если нужны разборки то логи все показывают.
Ну а смысл этой трехзавенки тогда, если она усложняет разработку? Я сторонник минимализма , если задача позволяет. Зачем делать сложно когда можно сделать проще, быстрее и меньшим составом разработчиков? У меня команда это два человека. А задачи непростые. Это как говорят не "джесоны перекладывать". Delphi меня вполне устраивает, и все приятные мелочи, которые можно одной строчкой реализовать, к примеру переключится автоматом на русский язык если курсор в поле ввода. Попробуйте это сделать на любом другом языке кроме С. Мода на web интерфейс только усложняет и удлиняет разработку и ничего не дает в общем. Delphi ceйчас в общем это не совсем тот Delphi, который был 20 лет назад, Теперь можно писать под все платформы. Появились и динамические массивы к примеру, чего в старых вариантах Delphi не было. Драйверы под любую БД есть. Даже для sqlite имеется драйвер.
Логика в БД, идентификация на сервере и настройки прав доступа по ролям в БД. Это то что я использую в разработке на чистом SQL. В качестве клиента есть и nocode (LabVIEW) и Delphi последней версии. Системы сложные. Однa из них описана в моей статье в хабр профиле. Даже мысли нe было использовать костыли вместо нативного SQL. Ну и оптимизация sql по скорости это наше все. Процедуры и функции sql более эффективны и упрощают разработку сложных приложений. К сожалению это понимает не каждый. У меня количество пользователей не миллионы, но задачи компенсируются значительной сложностью бизнес процессов. Поэтому логика в БД позволяет не только разрабатывать , но и относительно просто сопровождать и дорабатывать приложения при необходимости не ломая главного- бизнес модели.