А то, что беспилотники неизбежно будут людей калечить, и при этом непонятно кто будет ответственность нести и компенсации платить, это не в числе основных причин?
В ПДД чётко написано, что автомобиль — является источником повышенной опасности. В связи с чем, вред, причиненный жизни или здоровью граждан при вождении автомобиля , возмещается его водителем независимо от его вины.
Этот постулат - фундамент ПДД, и он абсолютно исключает беспилотники на дорогах общего пользования.
Oracle отрубил доступ к оплаченной поддержке. Заблокировал оплаченные лицензии, таким образом стал недоступен даже доступ к базе знаний по известным проблемам.
Для админа Oracle было бы полезно узнать, что в Postgre используется вместо rman, какая команда позволяет копировать файлы данных "на горячую" вместо alter tablespace begin backup и тому подобные вещи.
Дамп SQL упоминать в контексте резервного копирования, да еще первым пунктом...
В двух словах суть статьи:
Таск трекер разрешили только jira
Техдокументация и требования для разработки только confluence
Учет тестирования только в allure.
Исходники только в git (какой сервер, автору не сказали, наверное bitbucket)
Выбора нет, зато всё интегрировано из коробки, что экономит время на развёртывание и дает некое однообразие процессов всех команд.
Такие щекотливые вопросы, как
— максимальный объем работы для одной задачи в jira
— необходимость списания времени
— отчётность о работе
— планирование загрузки на будущие периоды
автор оставил без ответа.
Без ответов на эти вопросы рыдают менеджеры среднего и высшего звена, так как они становятся как бы «не при делах».
Как заставить людей этим всем пользоваться (даже если не удобно) без утвержденого регламента, тоже непонятно.
PS: ненавижу регламенты!
Не забудьте завести тикет в jira на доработку текста тикета в jira, а то ведь программисты могут лениться это сделать. И вам контролировать их будет проще.
Давайте скажем честно, переезд на удаленку - это катастрофа с точки зрения ИБ. Это всё равно что узников шарашки отправить на удаленку. Гарантировать сохранность никакой информации, к которой есть доступ через VPN, нельзя.
Статистика более гладкая, чем в других странах, да. Но это не доказывает, что она искусственно сглажена.
Я бы даже сказал, что скорее подозрительны именно скачки в данных, а не гладкий график, и надо пытаться объяснить, откуда они берутся. Можно предположить, что в других странах данные вводятся не день-в-день, а накапливаются. Поскольку автор манипулирует не первичными данными, а взятыми "откуда-то", то они могут в этом источнике браться срезами по официальным отчетам о заболевших, и срезы эти не ежедневны.
Объяснений может быть множество. Я не отрицаю возможность фальсификаций. Просто по опыту жизни в нашей стране считаю что они неизбежны. Но нужно понимать масштабы страны, и как работает многоуровневая система госуправления. В одном регионе может быть так, в другом иначе. В даже в разных районах. Многое зависит от личностей руководителей и исполнителей.
Данная статья не дает ничего в плане доказательства существования фальсификаций или объяснения природы их появления. Автор научился использовать технические инструменты анализа данных, но ничего не понимает в сути самих данных, источниках получения данных, в процессах, которые отражают эти данные. Это просто спекуляции с красивыми графиками и не более того.
Отказы взять ПЦР тесты у конкретных больных никак не могут объяснить якобы аномалию "ровно треть дней в нашей статистике имеют разницу с соседними днями менее чем на 1%". Предположим, на утренней летучке врачам говорят "сегодня тесты стараемся не брать, чтобы не превысить предписанный порог". Но такие указания можно дать только зная заранее, сколько может быть положительных тестов. А этом можно делать, например, если уже вчера произошел всплеск, но тогда он бы был отражен в статистике. Однозначно это не реально.
Сглаживать статистику можно только не регистрируя уже взятые положительные ПЦР тесты или перенося их на другие дни для сглаживания. Никаких доказательств этого в статье нет, то есть тема не раскрыта.
Вообще автор не знает достоверно, что означает дата в его данных, это дата взятия теста, получения результатов теста, дата постановки диагноза ковид или дата внесения одного из этих событий "в компьютер". И для разных стран это будут разные события и у них разные закономерности распределения. Нельзя просто взять выделить какую-то "аномалию" и сразу делать вывод о фальсификациях. А в такой важной теме это еще и безответственно.
Подход напоминает сисадмина, который уже знает, что надо регулярно делать бекап, но не знает, что также его надо регулярно проверять (восстанавливать) .
Концентрация на улучшении процесса написания, а не использования документации.
Если цель ведения документации — спихнуть что-то заказчику, чтобы формально закрыть договор, то подход имеет право на жизнь.
Если документация пишется, чтобы ею пользовались, то главным критерием улучшений должно быть удобство использования и качество содержания. Отсюда вытекает confluence или другая продвинутая wiki с мощным поиском, плагинами для диаграмм и прочими плюшками, кстати версионирование страниц там есть и без гита. А также необходимо регулярное чтение документации не только самим писателем или разработчиком темы, но и аналитиком или другим человеком "со стороны", который вдумчиво будет пытаться сопоставить набор слов с тем, что они в реальности описывают, задавать вопросы и требовать уточнений.
Наверное merge request имеет право на жизнь, но это только если трудится целая группа писателей.
Программисты должны непременно быть вовлечены, но гит использовать для этого вовсе не обязательно.
Главная проблема технической документации — ее бесполезность в силу формального подхода к написанию и быстрого "протухания". Указанный в статье подход никак с этими проблемами не борется. Похоже на карго-культ методик и инструментов разработки.
Если имеется ввиду код под «спойлером» «Исходный код демонстрационной процедуры, то там уже лучше, так как в блоке when others нет rollback.
Но все равно недостаточно хорошо, потому что там не инициализируются p_errcode и p_errtext и при этом нет raise. Таким образом вызывающая процедура не знает о том, что в данной процедуре произошла непредвиденная ситуация. Что приведет к сложновылавливаемым ошибкам.
Ну и в принципе под when others подпадает и ошибка отсутствия нужной партиции для вставки записи, и ora-600 и много других непредвиденных системных сбоев, которые должны, просто обязаны останавливать исполнение всей последовательности вызовов и „орать“ в мониторинг о срочном вмешательстве поддержки. Поэтому в when others должен быть raise.
«Все объекты базы данных (функции, процедуры) в обязательном порядке должны завершаться блоком обработки исключений с последующим логированием события».
А почему обязательно все? Почему не ловить exception только в процедурах верхнего уровня, которые вызываются пользовательской сессии или из джоба?
Ну или хотя бы только в процедурах, которые есть в заголовке пакета, и потенциально могут быть вызваны пользовательской сессии или из джоба?
Я не сужу о всей статье, и подход в целом здравый. Я критикую конкретный код, потому что вся суть предложенной в статье концепции логирования всех исключительных ситуаций — это обработчик этих ситуаций в каждой процедуре и логирование в нем.
Куда логировать, в таблицы или во внешний инструмент, как потом мониторить, это уже детали. Суть в правиле — каждый exception должен логироваться в той процедуре, в которой он произошел. И типовой обработчик — это не просто пример, а важнейшая часть этой концепции, которую нужно один раз написать как шаблон, а потом постоянно вставлять в код всем разработчикам. Ошибки в этом шаблоне, раскопированные по всему коду, могут просто похоронить проект.
Если я так сделаю на каком-либо проекте, то меня будут вспоминать проклиная и ненавидя…
Почему? Например, компиляцию нельзя выполнить, если в коде есть синтаксическая ошибка. Это же не расстраивает программиста, а наоборот, помогает.
Если у вас на проекте имеются требования к оформлению кода, то автоматический контроль соблюдения этих требований упростит жизнь программистам. За это они спасибо скажут. Главное делать этот контроль оптимально, чтобы только реальные проблемы не допускал, а не вставлял палки в колеса.
На самом деле это не такая частая проблема, да иногда забывают и ничего не мешает добавить позже, все решается обычным кодревью.
Я часто делаю код ревью. При этом предлагаете пересчитывать на глаз количество параметров в заголовке процедуры и в ее хвосте, которые могут быть за сотни строк друг от друга? А параметров может быть штук 10. Или так ПО КАЖДОЙ процедуре? И на это будет тратить свое время самый ценный трудовой ресурс команды (обычно ревью делает тимлид)?
«если транзакция падает с ошибкой (типа «when others then»), то данную транзакцию завершают полным откатом изменений т.е. либо алгоритм отрабатывает без ошибок и сохраняем результат, либо завершаем алгоритм и не сохраняем вообще ничего».
Так как раз ваш предлагаемый подход в КАЖДОЙ процедуре глушить все иск.ситуации и делать rollback противоречит этой здравой концепции.
Предположим у нас есть управляющая процедура Main (в ней одна транзакция, в конце процедуры commit), которая вызывает по очереди три процедуры, которые делают какие-то этапы общей транзакции, выполняют dml. Назовем их Step1, Step2, Step3. Если в Step2 произойдет exception, то произойдет откат dml, выполненных в Step1 и Step2. Далее, поскольку raise не сделан, управление перейдет в Step3, и затем общий commit в Main. В итоге мы получили в базе не «все или ничего», а только dml из Step3, что при разборе крайне загадочно и поставит разработчика в тупик.
Если же использовать rollback to savepoint Step2 и raise, управляющая процедура получит информацию, что Step2 не выполнен и сможет далее принять решение, можно ли переходить к Step3 или нужно аварийно завершиться без commit. Если в Main программист не предусмотрел блок обработки ошибок, то после exception в Step2 Main завершится аварийно без commit и мы получим «все или ничего».
Мое мнение такое, что when others then… raise и rollback to savepoint в обработчике ошибок общего назначения — это как раз должно использоваться всегда, а вот отказ от них возможен в редких частных случаях. Такая практика поможет избежать множества сложновылавливаемых ошибок. Приведенные примеры показывают, как, создавая вроде бы полезную фичу для борьбы с ошибками, фактически добавлять новые ошибки, которые будут «стрелять» при обработке исключительных ситуаций. Как маскировать реальные причины проблемы.
Самая сложная категория багов — это баги, допущенные в обработчике исключительных ситуаций. И обработчик из вашего примера их содержит.
Список параметров каждой процедуры есть в системных view. Можно написать функцию проверки наличия всех параметров в тексте пакета/процедуры и запускать эту функцию по триггеру в момент компиляции пакета/процедуры на тестовом или разработческом стенде.
Тогда программист не сможет забыть указать параметр.
Обработка when others без raise внутри — отличный способ выстрелить себе в ногу. Вызванная процедура отработала вхолостую, вызывающая об этом ничего не знает и продолжает как ни в чем не бывало.
Архитекторы у вас боятся пустых полей, зато не боятся лишнего insert. Очень странные архитекторы.
А ещё rollback без savepoint, который откатывает весь dml, сделанный в вызывающей процедуре. Такая мина заложена, что когда она взорвется, уйдет не один час на то, чтобы понять, почему данные не сохраняются в базу.
Вероятность 50/50, что программист при добавлении параметра в процедуру забудет добавить его в строку p_paramvalue и в самый неподходящий момент выяснится, что его значение не залогировано, а оно-то как раз и необходимо.
Хороший набор антипаттернов для включения в каждую процедуру!
Посмотрите, как устроены гистограммы статистики, какой объем они занимают. Для запросов, которые обрабатывают маленький объем данных, но по большому количеству таблиц со сложными where, построение запроса может потребовать вычитать кратно больше данных, чем собственно выполнение запроса.
Расходы ерундовые, если разработчики позаботились о том, чтобы каждый раз не делался hard_parse.
Я не знаю как в PG, а в Oracle например на идентичный текст запроса может быть одновременно множество планов выполнения, которые используются разными сессиями. Потому что планы зависят не только от текста запроса, но и еще от кучи параметров окружения сессии.
То есть даже использование bind переменных не гарантирует отсутствия повторного hard-parse.
И вот если разработчики об этом не подозревают или вообще используют какой-то кривой генератор SQL который каждый раз новый текст генерит, или литералы, то потом встает вопрос о горизонтальном масштабировании БД, выделении реплик и т.п.
Если же с базой данных работать с умом, то можно прекрасно без этого обходиться гораздо-гораздо дольше.
База данных — сердце любой крупной системы. Оптимизация в ней или в работе с ней может многократно ускорить работу, а отношение к БД как черному ящику с данными, приводит потом к появлению костылей типа самописных кешей и т.п.
Вы писали «Раздавать всем права вручную не кажется мне более безопасным», и пояснили, что это не более безопасно, чем «логика в коде». Не вижу логической связи.
Ага, только когда логика в коде, пользователь кода в принципе не может прочитать или вызвать никакие таблицы, вью, функции или процедуры. У него нет прямого доступа в БД, в отличие от вашего варианта. Поэтому и права на них настраивать не надо и следить за их соблюдением.
Чаще всего консистентность данных в базе разрушается не пользователями, а программистами, которые допускают ошибки в бекенде или руками правят данные в базе или запускают некорректные скрипты пакетной обработки. И вот от этого всего защищают бизнес-правила инкапсулированные в БД в виде FK, констрейнов, триггеров или полного запрета на DML и замену его процедурами изменения данных, которые контролируют их согласованность.
И если этого не делать, то сами программисты бекенда потом вынуждены в коде делать кучу лишних проверок и обработчиков неконсистентных данных. Документов без строк, ссылок на несуществующие или неактуальные элементы справочников, запросы, возвращающие несколько записей, когда по логике должна быть одна, неуникальная нумерация (буквально на той неделе столкнулись в смежной системе) и т.п.
Потому что все эти неконсистентности в данных обычно никто не правит или просто не может выловить, откуда они появляются.
И как тут уже кто-то писал, начинаются ежедневные запуски процедур пересчета регистра остатков, и прочие чисто технические обработки, которые мусор под ковер заметают.
Поэтому НУЖНО бизнес-логику, относящуюся к консистентности, контролировать в БД и приходится обрезать права всем, кто обращается в БД, в том числе бекенду.
Не ровно то же, потому запретить доступ всему кроме конкретного сервиса в общем случае нельзя. Знаешь логин/пароль, ip не забанен — добро пожаловать в базу делать ad hoc sql нарушая все правила бекенда.
Ну и во-вторых, зачем тащить это на бекенд со всеми его недостатками, когда это отлично делается в базе, никаких красивых фреймворков, менеджеров зависимостей, синтаксических сахаров не надо для таких задач.
Таким образом убирается лишняя точка отказа, причем очень вероятного отказа.
На функцию нужен execute, хотя это зависит наверное от СУБД. В oracle — execute.
Если персданные критичны, то они не возвращаются функцией, потому что критичны и видеть их в списке никому не требуется.
К чему вы клоните своими вопросами?
А то, что беспилотники неизбежно будут людей калечить, и при этом непонятно кто будет ответственность нести и компенсации платить, это не в числе основных причин?
В ПДД чётко написано, что автомобиль — является источником повышенной опасности. В связи с чем, вред, причиненный жизни или здоровью граждан при вождении автомобиля , возмещается его водителем независимо от его вины.
Этот постулат - фундамент ПДД, и он абсолютно исключает беспилотники на дорогах общего пользования.
Для админа Oracle было бы полезно узнать, что в Postgre используется вместо rman, какая команда позволяет копировать файлы данных "на горячую" вместо alter tablespace begin backup и тому подобные вещи.
Дамп SQL упоминать в контексте резервного копирования, да еще первым пунктом...
Помилуйте, зачем такое публиковать?
Таск трекер разрешили только jira
Техдокументация и требования для разработки только confluence
Учет тестирования только в allure.
Исходники только в git (какой сервер, автору не сказали, наверное bitbucket)
Выбора нет, зато всё интегрировано из коробки, что экономит время на развёртывание и дает некое однообразие процессов всех команд.
Такие щекотливые вопросы, как
— максимальный объем работы для одной задачи в jira
— необходимость списания времени
— отчётность о работе
— планирование загрузки на будущие периоды
автор оставил без ответа.
Без ответов на эти вопросы рыдают менеджеры среднего и высшего звена, так как они становятся как бы «не при делах».
Как заставить людей этим всем пользоваться (даже если не удобно) без утвержденого регламента, тоже непонятно.
PS: ненавижу регламенты!
Давайте скажем честно, переезд на удаленку - это катастрофа с точки зрения ИБ. Это всё равно что узников шарашки отправить на удаленку. Гарантировать сохранность никакой информации, к которой есть доступ через VPN, нельзя.
Все держится на чистом доверии к сотрудникам.
Статистика более гладкая, чем в других странах, да. Но это не доказывает, что она искусственно сглажена.
Я бы даже сказал, что скорее подозрительны именно скачки в данных, а не гладкий график, и надо пытаться объяснить, откуда они берутся.
Можно предположить, что в других странах данные вводятся не день-в-день, а накапливаются. Поскольку автор манипулирует не первичными данными, а взятыми "откуда-то", то они могут в этом источнике браться срезами по официальным отчетам о заболевших, и срезы эти не ежедневны.
Объяснений может быть множество. Я не отрицаю возможность фальсификаций. Просто по опыту жизни в нашей стране считаю что они неизбежны. Но нужно понимать масштабы страны, и как работает многоуровневая система госуправления. В одном регионе может быть так, в другом иначе. В даже в разных районах. Многое зависит от личностей руководителей и исполнителей.
Данная статья не дает ничего в плане доказательства существования фальсификаций или объяснения природы их появления. Автор научился использовать технические инструменты анализа данных, но ничего не понимает в сути самих данных, источниках получения данных, в процессах, которые отражают эти данные. Это просто спекуляции с красивыми графиками и не более того.
Отказы взять ПЦР тесты у конкретных больных никак не могут объяснить якобы аномалию "ровно треть дней в нашей статистике имеют разницу с соседними днями менее чем на 1%". Предположим, на утренней летучке врачам говорят "сегодня тесты стараемся не брать, чтобы не превысить предписанный порог". Но такие указания можно дать только зная заранее, сколько может быть положительных тестов. А этом можно делать, например, если уже вчера произошел всплеск, но тогда он бы был отражен в статистике. Однозначно это не реально.
Сглаживать статистику можно только не регистрируя уже взятые положительные ПЦР тесты или перенося их на другие дни для сглаживания. Никаких доказательств этого в статье нет, то есть тема не раскрыта.
Вообще автор не знает достоверно, что означает дата в его данных, это дата взятия теста, получения результатов теста, дата постановки диагноза ковид или дата внесения одного из этих событий "в компьютер". И для разных стран это будут разные события и у них разные закономерности распределения. Нельзя просто взять выделить какую-то "аномалию" и сразу делать вывод о фальсификациях. А в такой важной теме это еще и безответственно.
Подход напоминает сисадмина, который уже знает, что надо регулярно делать бекап, но не знает, что также его надо регулярно проверять (восстанавливать) .
Концентрация на улучшении процесса написания, а не использования документации.
Если цель ведения документации — спихнуть что-то заказчику, чтобы формально закрыть договор, то подход имеет право на жизнь.
Если документация пишется, чтобы ею пользовались, то главным критерием улучшений должно быть удобство использования и качество содержания. Отсюда вытекает confluence или другая продвинутая wiki с мощным поиском, плагинами для диаграмм и прочими плюшками, кстати версионирование страниц там есть и без гита. А также необходимо регулярное чтение документации не только самим писателем или разработчиком темы, но и аналитиком или другим человеком "со стороны", который вдумчиво будет пытаться сопоставить набор слов с тем, что они в реальности описывают, задавать вопросы и требовать уточнений.
Наверное merge request имеет право на жизнь, но это только если трудится целая группа писателей.
Программисты должны непременно быть вовлечены, но гит использовать для этого вовсе не обязательно.
Главная проблема технической документации — ее бесполезность в силу формального подхода к написанию и быстрого "протухания". Указанный в статье подход никак с этими проблемами не борется. Похоже на карго-культ методик и инструментов разработки.
Но все равно недостаточно хорошо, потому что там не инициализируются p_errcode и p_errtext и при этом нет raise. Таким образом вызывающая процедура не знает о том, что в данной процедуре произошла непредвиденная ситуация. Что приведет к сложновылавливаемым ошибкам.
Ну и в принципе под when others подпадает и ошибка отсутствия нужной партиции для вставки записи, и ora-600 и много других непредвиденных системных сбоев, которые должны, просто обязаны останавливать исполнение всей последовательности вызовов и „орать“ в мониторинг о срочном вмешательстве поддержки. Поэтому в when others должен быть raise.
А почему обязательно все? Почему не ловить exception только в процедурах верхнего уровня, которые вызываются пользовательской сессии или из джоба?
Ну или хотя бы только в процедурах, которые есть в заголовке пакета, и потенциально могут быть вызваны пользовательской сессии или из джоба?
Куда логировать, в таблицы или во внешний инструмент, как потом мониторить, это уже детали. Суть в правиле — каждый exception должен логироваться в той процедуре, в которой он произошел. И типовой обработчик — это не просто пример, а важнейшая часть этой концепции, которую нужно один раз написать как шаблон, а потом постоянно вставлять в код всем разработчикам. Ошибки в этом шаблоне, раскопированные по всему коду, могут просто похоронить проект.
Так как раз ваш предлагаемый подход в КАЖДОЙ процедуре глушить все иск.ситуации и делать rollback противоречит этой здравой концепции.
Предположим у нас есть управляющая процедура Main (в ней одна транзакция, в конце процедуры commit), которая вызывает по очереди три процедуры, которые делают какие-то этапы общей транзакции, выполняют dml. Назовем их Step1, Step2, Step3. Если в Step2 произойдет exception, то произойдет откат dml, выполненных в Step1 и Step2. Далее, поскольку raise не сделан, управление перейдет в Step3, и затем общий commit в Main. В итоге мы получили в базе не «все или ничего», а только dml из Step3, что при разборе крайне загадочно и поставит разработчика в тупик.
Если же использовать rollback to savepoint Step2 и raise, управляющая процедура получит информацию, что Step2 не выполнен и сможет далее принять решение, можно ли переходить к Step3 или нужно аварийно завершиться без commit. Если в Main программист не предусмотрел блок обработки ошибок, то после exception в Step2 Main завершится аварийно без commit и мы получим «все или ничего».
Самая сложная категория багов — это баги, допущенные в обработчике исключительных ситуаций. И обработчик из вашего примера их содержит.
Список параметров каждой процедуры есть в системных view. Можно написать функцию проверки наличия всех параметров в тексте пакета/процедуры и запускать эту функцию по триггеру в момент компиляции пакета/процедуры на тестовом или разработческом стенде.
Тогда программист не сможет забыть указать параметр.
Обработка when others без raise внутри — отличный способ выстрелить себе в ногу. Вызванная процедура отработала вхолостую, вызывающая об этом ничего не знает и продолжает как ни в чем не бывало.
Архитекторы у вас боятся пустых полей, зато не боятся лишнего insert. Очень странные архитекторы.
А ещё rollback без savepoint, который откатывает весь dml, сделанный в вызывающей процедуре. Такая мина заложена, что когда она взорвется, уйдет не один час на то, чтобы понять, почему данные не сохраняются в базу.
Вероятность 50/50, что программист при добавлении параметра в процедуру забудет добавить его в строку p_paramvalue и в самый неподходящий момент выяснится, что его значение не залогировано, а оно-то как раз и необходимо.
Хороший набор антипаттернов для включения в каждую процедуру!
Расходы ерундовые, если разработчики позаботились о том, чтобы каждый раз не делался hard_parse.
Я не знаю как в PG, а в Oracle например на идентичный текст запроса может быть одновременно множество планов выполнения, которые используются разными сессиями. Потому что планы зависят не только от текста запроса, но и еще от кучи параметров окружения сессии.
То есть даже использование bind переменных не гарантирует отсутствия повторного hard-parse.
И вот если разработчики об этом не подозревают или вообще используют какой-то кривой генератор SQL который каждый раз новый текст генерит, или литералы, то потом встает вопрос о горизонтальном масштабировании БД, выделении реплик и т.п.
Если же с базой данных работать с умом, то можно прекрасно без этого обходиться гораздо-гораздо дольше.
База данных — сердце любой крупной системы. Оптимизация в ней или в работе с ней может многократно ускорить работу, а отношение к БД как черному ящику с данными, приводит потом к появлению костылей типа самописных кешей и т.п.
Чаще всего консистентность данных в базе разрушается не пользователями, а программистами, которые допускают ошибки в бекенде или руками правят данные в базе или запускают некорректные скрипты пакетной обработки. И вот от этого всего защищают бизнес-правила инкапсулированные в БД в виде FK, констрейнов, триггеров или полного запрета на DML и замену его процедурами изменения данных, которые контролируют их согласованность.
И если этого не делать, то сами программисты бекенда потом вынуждены в коде делать кучу лишних проверок и обработчиков неконсистентных данных. Документов без строк, ссылок на несуществующие или неактуальные элементы справочников, запросы, возвращающие несколько записей, когда по логике должна быть одна, неуникальная нумерация (буквально на той неделе столкнулись в смежной системе) и т.п.
Потому что все эти неконсистентности в данных обычно никто не правит или просто не может выловить, откуда они появляются.
И как тут уже кто-то писал, начинаются ежедневные запуски процедур пересчета регистра остатков, и прочие чисто технические обработки, которые мусор под ковер заметают.
Поэтому НУЖНО бизнес-логику, относящуюся к консистентности, контролировать в БД и приходится обрезать права всем, кто обращается в БД, в том числе бекенду.
Ну и во-вторых, зачем тащить это на бекенд со всеми его недостатками, когда это отлично делается в базе, никаких красивых фреймворков, менеджеров зависимостей, синтаксических сахаров не надо для таких задач.
Таким образом убирается лишняя точка отказа, причем очень вероятного отказа.
Если персданные критичны, то они не возвращаются функцией, потому что критичны и видеть их в списке никому не требуется.
К чему вы клоните своими вопросами?