А есть ли шанс, что вместо запускаемых десятков технических сервисов (сценариев) по различным направлениям деятельности будет проведена цифровая унификация для их минимизации?
99,99% предприятий ведут учёт в цифровом виде в главной электронной книге с общей структурой (Дата, Дебет, Кредит, Аналитика, Сумма)
Из-за цифрового невежества в совокупности с первобытно-бумажным консерватизмом мы продолжаем строить системы отталкиваясь от принятых ранее бумажных форм отчетности. Для каждого вида отчётности создаём свою электронную структуру передачи данных, каждый раз заново программисты реализовывают алгоритмы для передачи данных и проверки контрольных соотношений.
А ведь можно один раз технически проработать универсальную структуру передаваемых данных (Дата, Дебет, Кредит, Аналитика, Сумма). Унификация структуры передаваемых данных не столько снизит затраты на программистов, сколько повысит надёжность всей системы, уменьшив количество вероятных точек сбоя.
Был у меня такой случай. Запросил как-то у LLM: "Имеются таблицы приходов и расходов со структрой такой-то.... Составь SQL для получения данных о реализации диванов за последний месяц"
Вернул запрос на получение данных из таблицы приходов.
Уточняю у LLM, почему реализация - это приход? Отвечает: "Реализация - это поступление выручки - т.е. данные берем из таблицы приходов"
LLM отлично транслирует текст с одного языка в другой, но смысл текста может измениться, и нам ещё нужно научиться работать с данным инструментом в реальх задачах.
Некоторые популярные модели некорректно предлагают простейшие запросы: "Имеются таблицы приходов и расходов номенклатуры на складе, сформируй SQL расчета остатков на складе на указанную дату" - отличный вопрос для собеседования.
Не пора ли ФНС перейти от первобытно-бумажных электронных отчётов по отдельным показателям к единому цифровому отчёту по деятельности предприятия?
Все предприятия давно ведут баланс в едином электронно-цифровом виде Дт-Кт-Сумма-Аналитика. Однако, продолжают формировать сотню (бывших бумажных) электронных сводных отчетов со множеством контрольных сумм, для проверки корректности заполненных показателей. Налог 3 продолжает традицию создавать отдельный сценарий под каждый показатель отчётности.
Сколько можно было бы сократить человеко-часов, заменив сотню узко-специализированных сценариев обмена на один универсальный, который уже действует на каждом предприятии (Дт-Кт-Сумма-Аналитика).
Предложенный метод "Учётной системы" применяется для управления предприятиями. Объекты в справочнике участвуют в различных регистрах - состояниях (моделях). Вычисления в регистрах могут быть взаимосвязаны транзакциями. Такой подход победил ООП и не даёт разбить на микросервисы ERP системы.
ООП и микросервисы - это не про архитектуру, это про командную работу, в которой удобно за каждым микросервисом или объектом закрепить ответственного и давить на него, требуя рабочий код в рамках возложенной ответственности, глубоко не вникая в его потребности.
Учётная система - комплексный подход к оптимизации связей элеметов. Кажется не сложно продумать заранее:
Регистр состояний (перчатка новая, перчатка требует починки);
Регистр владения (какие перчатки какому герою принадлежат);
Регистр столкновения юнитов (для всех перчаток, мечей, кольчуг проверяется их пересечение в 3д модели);
Другие регистры.
В этом подходе взаимосвязанных регистров размывается ответственность. Должен появиться архитектор, которого будут клевать со всех сторон, но который сможет убедить участников проекта сохранять компромис между функциональностью и простотой архитектуры.
ВЫВОД1: Описанная проблема не архитектурная, а организационная. Когда в команде распределяетя работа:
Начинающие разобьются на независимые объекты;
Опытные уже думают о группах сервисов состояний объектов;
Прожаренные смогут возглавить разработку по упрощённым шаблонам, не распыляясь на детализацию.
ВЫВОД2: Любой шаблон - устаревшая архитектура. Придет однажды новичек с новым объектом, сломает шаблон и все начнется сначала.
Пример про иерархию привел только как пример первостепенной, но не изученной области. Соответственно про простоту технологий говорить пока рано.
При изменении прав нагрузка будет - чтобы забрать полномочия.
К процессу выборки данных вопросов нет, смущает наличие функции в СУБД способной принять и переварить текст запроса с перечислением миллионов идентификаторов. При этом, с ростом объема данных размер текста запроса будет только увеличиваться.
Идеи инженеров-программистов не ограничены физическими законами, как у инженеров-конструкторов летательных аппаратов, но также регулярно разбиваются на реальных испытаниях.
Красиво, но не соответствует реальным потребностям:
Тысячи документов ассоциировать с правами для каждого пользователя - серьезная нагрузка. Особенно, если пользователь перешёл на новое место работы и все ранее выданные права необходимо пересмотреть по всем историческим документам;
Если у пользователя доступ предоставлен к миллиону документов, какого размера запрос отправится в СУБД чтобы показать список этих документов?
Подобные попытки спрятать логику в некую библиотеку разбиваются на реальных задачах. На сегодняшний день задача не решена и не имеет достаточной теоретической базы.
Например, задачу прав доступа нужно рассматривать со структуры предприятия, где права делегируются сверху-вниз, чтобы у подчинённого прав было не более чем у вышестоящего руководителя. А на практике, права руководителя собирают, как правило, снизу-вверх, админам проще дать права подчинённым, а руководителей включать во все возможные группы, или сделать одну супер группу, что тоже не упрощает раздачу прав.
Расстановка приоритетов, резервирование ресурсов, запуск оптимальных партий по нескольким проектам;
Исполнение плана работ;
Контроль качества, сроков, технологии;
Упрощение его у всякого рода "консультантов" до План-Факт-Контроль-Корректировка приводит к рождению неполноценных автоматизированных систем, которые внедряются "авторитетными" подрядчиками, подсаживая предприятия на бесконечную поддежку и доработку...
На фронте можно ещё проще, это же не многопользовательский режим. В рамках одной формы на каждый клик кнопки, на каждое изменение реквизита форма собирает со всех кортеж значений, обрабатывает скриптом-обработчиком (на любом языке) из нажатого компонента и рассылает всем результат в виде нового кортежа значений.
Интерфейсы (props, методы, события) ваших компонентов и модулей становятся чище и удобнее, так как вы проектируете их с точки зрения "потребителя"
В свое время ООП тоже пытались применить для работы с базами данных от задач потребителя. Как объекты предметной области рисовали, так и API для бэкенда предлагали реализовывать. Код был прекрасен с точки зрения тестов и поддержки. Но не работал эффективно с точки зрения производительности на больших массивах данных.
С точки зрения пользователя удобно рассчитать зарплату каждому сотруднику индивидуально, загружая из хранилища только необходимые данные. А с точки зрения машины на несколько порядко быстрее, если зарплату всем сотрудникам рассчитывать в потоке, предварительно загрузив требуемые данные в буфер.
Борьба между удобством пользователя и производительностью машины бесконечна. Где-то, благодаря поднявшейся производительности машины, мы позволили себе создать удобные функции, классы, интерфейсы. Но возрастающее количество обрабатываемых данных продолжает давить на разработчиков, наши заранее продуманные простые функции и классы снова превращаются в сборище исключений, пометок о техническом долге, пропущенных тестах. Иначе задачи бы не сдавались бы в прод, а мы бы остались вечными студентами в поисках чистого кода.
Принцип "Все является файлом" однажды всё-таки должен быть заменен на "Все является элементом структуры", где для каждого элемента присваивается совокупность идентификаторов и имён, например
code - человеко-ориентированный регистрозависимый идентификатор, не меняющийся при копировании между средами (системами) исполнения (хранения)
full_name - регистронезависимое отображаемое для пользователя имя элемента
Командная строка, пути к файлам с такими структурами может усложниться превратившись в подобие json. Конечно, в этом случае ОС с клавиатуры админить напрямую не получиться. Но ведь появился ИИ, который любой текст при наличии словаря легко преобразует в json, командная строка легко возродится в новом качестве.
Уже парочка популярных СУБД есть, но в них нет RLS :-). А вот у Postgres есть PAM, есть статьи, как все связать вместе. Есть ещё неожиданный пример - в платформе 1с реализовали и RLS, и OpenID. Так что направление и тут развивается, был бы спрос.
Не вполне понятно как это должно работать.
Непонятно какую пользователю присвоить роль, а ролям назначит политику rls? Это творческий процесс, зависит от самой задачи.
...тут можно просто передать этот пароль СУБД. Хотя это уже небезопасно
Передача пароля - совсем уже примитив по сегодняшним технологиям. Рассмотрите как работает Kerberos или OpenID. Это не простые решения по администрированию, но важные подходы для любых систем.
...для проверок доступно только его имя
Никогда, слышите, никогда не привязывайте правила RLS к пользователю напрямую (исключение только для его личных, не относящихся к профессиональной деятельности сообщений).
Скрытый текст
Надеюсь, когда нибудь появится время, влезу в исходный код ядра популярной ОС, чтобы изьять все права на файлы для Owner, обесценивающие все труды по настройке прав по группам пользователей.
Правила RLS привязываются к ролям (группам) пользователей. Все действия пользователь должен совершать в рамках своих ролей в системе. Если это система управления предприятием, то роли совпадают со штатным расписанием предприятия - работники приходят и уходят, а правила доступа остаются неизменными (если не меняются полномочия в самом штатном расписании).
Сопоставление и настройка правил доступа между ролями пользователей и объектами данных - это всегда трудный творческий процесс, независимо от уровня реализации - на уровне интерфейса, сервера приложений или сервера СУБД.
А какие ещё проблемы бывают? Пользователь зашёл под своими правами, делает в любом случае что хочет в рамках выданных прав, хоть БД удаляет, если ему такие права даны, как с инъекциями, так и без. Или чего-то ещё?
читаемый SQL (без CTE...
CTE - это и есть организация структуры запроса. На производительность не влияет, производительность сильнее просаживается, как только данные с носителя начинают читаться. Дополнительно оптимизатор корректно запрос оптимизирует, видя статические данные из СТЕ. Совокупность OR и AND конечно накладные расходы, но выглядит не хуже if или case, когда запрос по двум языкам размазан и для его тестирования в консоле нужно очистить от всех этих накладок
Всегда можно посмотреть, что генерирует ORM
Я несколько о другом, я про LOW-CODE + SQL в котором аналитик сам прикладное решение создаёт, без программиста. Правда полноценных таких решений пока нет. Но мы же обсуждаем противостояния подходов, следовательно косвенно влияем на приоритеты для выбора разработчиков будущих решений.
Решениe 1. Включить авторизацию на уровне СУБД, настроить доступ, в т.ч. RLS - тогда пользователь будет делать только то, что позволено. Проблема пока ещё в отсутствии нормальной методологии (культуры) формирования структуры ролей и прав доступа, непроизводительная реализация RLS, но постепенно к разработчикам СУБД понимание приходит.
Решение 2. Параметризованные запросы - зло с точки зрения дизайна sql. SQL имеет на выходе набор(ы) данных. На вход ему также удобно подавать набор данных, к которому обращаться как к таблице, без всяких многочисленных вставок параметров в разных местах запроса. Такого интерфейса СУБД пока не имеют, поэтому как универсальное решение, упаковывать параметры и значения в json далее распаривать их в CTE как табличку из json с одной записью и использовать в разных местах. Вредоносные sql инъекции съедятся на этапе упаковки в json, конечно при условии корректной (один раз) отработки передачи json строки в качестве параметра.
Сложность формирования сложных SQL-запросов
Если параметры раскидывать по SQL, конечно, такой код не читабельный. Все параметры удобно описать вначале в СТЕ (WITH...) затем использовать в запросе, на скорость выполнения запроса критически не повлияет
WITH params AS (
SELECT
COALESCE(:is_a, false) as is_a
, COALESCE(:a, 0) as a
, COALESCE(:is_b, false) as is_b
, COALESCE(:b, 0) as b
)
SELECT
...
WHERE
(SELECT p.is_a FROM params p)
AND (SELECT p.a FROM params p)=111
OR
(SELECT p.is_b FROM params p)
AND (SELECT p.b FROM params p)=222
Пример может показаться перегруженным, но это реальный шаблон помогающий для написания больших, сложных запросов.
LOW-CODE
Как-то аналитик быстрее понимает SQL, чем ORM. Поэтому LOW-CODE + SQL, а ORM пусть покурит в сторонке.
Можно по косвенным признакам определить, что крупные предприятия пока ещё не вкусили полноценных «ЕРП», успешные внедрения были либо в какой узкой специализации, либо поверхностные: 1. «ЕРП» еще не решали методические и технические проблемы разделения прав доступа. Сотня бизнес ролей должны быть завязаны по доступу на тысячи таблиц в БД. Текущие реализации RLS кладут производительность систем. Единственный удовлетворяющий по производительности RLS реализован в ORCLE – выглядит как «на коленках» собранное решение в котором текстовые строки сгенерированные админом тупо подставляются в каждый sql. Но даже при имеющихся технических решениях отсутствуют обсуждения проблем делегирования прав сверху вниз или проблем предоставления пользователю одновременного доступа к таблице на чтение и запись в зависимости от контекста записи (кладовщик должен редактировать накладные оформляемые на его склада, читать накладные направляемые ему на склад, к другим накладным он не должен иметь доступ).
2. «ЕРП» не кушали электронный технологический состав изделия из PLM. На крупных предприятиях конструкторская «Деталь» в технологическом составе одновременно может быть получена разными маршрутами, например отлита, вырезана на фрезере или приобретена у стороннего поставщика, В этом случае в технологическом составе PLM появляются новые объекты «Деталь литая», «Деталь вырезанная» и «Деталь покупная». Производить нужно по маршруту технологическую деталь а на промежуточный склад должна поступить конструкторская «Деталь». Какая «ЕРП» учитывает такие особенности?
3. «ЕРП» не охватывают всю хозяйственную деятельность предприятия, отгрызают только какие-то островки для автоматизации. При полном охвате деятельности, естественным результатом будет выдача выходного пособия для всех бухгалтеров, т.к. расчет стоимости становится по истине автоматизирован, для расчета прибыли и убытков остаётся только формировать общий расчет бухгалтерских проводок в конце отчётного периода. 1С, известная своими бухгалтерскими решениями, попыталась реализовать такой сценарий в своей «ЕРП» – оставить в должности только Главного бухгалтера для нажимания один раз в месяц кнопки закрытия периода. Первый блин, как говорится, оказался «комом», настройка всех справочников, да и сами реализованные процессы вызывают много вопросов. Это только показывает, что по настоящему автоматизированные системы управления крупными предприятиями у нас ещё впереди.
На самокате, велосипеде оттолкнулся ногой, есть запас инерции, чтоб поймать равновесие и проехать несколько метров без педалей.
На моноколесе такого запаса инерции нет, оттолкнулся ногой, встал ею на подножку, надо сразу себя перебороть, ногами (телом) продавить педали (газовать).
Стоять без движения на моноколесе, как на двухколесном гироскуторе, тоже не получится.
… навыки удержания баланса полученные на любом виде техники вроде самоката, велосипеда, роликов и прочих коньков, никак не помогают...
Главное отличие моноколеса — само оно не катится. Обучение через «оттолкнулся-поехал», как с самокатом, велосипедом, и т.п. здесь не работают, они в первую очередь и мешают.
В моноколесе главное — «газовать», хочешь удерживать равновесие, должен ехать, т.е постоянно давить на педаль — вперед, даже при повороте. Вырабатываешь этот инстинкт, дальше интуиция подскажет.
Последнее время подсовываю кандидатам составить простой SQL:
“Имеется таблица приходов и расходов номенклатуры по складу. Требуется составить запрос получения остатков.“
ИИ, за редким исключением, генерит нормальный запрос...
Начинающие тоже торопятся и делают ошибки.
А есть ли шанс, что вместо запускаемых десятков технических сервисов (сценариев) по различным направлениям деятельности будет проведена цифровая унификация для их минимизации?
99,99% предприятий ведут учёт в цифровом виде в главной электронной книге с общей структурой (Дата, Дебет, Кредит, Аналитика, Сумма)
Из-за цифрового невежества в совокупности с первобытно-бумажным консерватизмом мы продолжаем строить системы отталкиваясь от принятых ранее бумажных форм отчетности. Для каждого вида отчётности создаём свою электронную структуру передачи данных, каждый раз заново программисты реализовывают алгоритмы для передачи данных и проверки контрольных соотношений.
А ведь можно один раз технически проработать универсальную структуру передаваемых данных (Дата, Дебет, Кредит, Аналитика, Сумма). Унификация структуры передаваемых данных не столько снизит затраты на программистов, сколько повысит надёжность всей системы, уменьшив количество вероятных точек сбоя.
Был у меня такой случай. Запросил как-то у LLM: "Имеются таблицы приходов и расходов со структрой такой-то.... Составь SQL для получения данных о реализации диванов за последний месяц"
Вернул запрос на получение данных из таблицы приходов.
Уточняю у LLM, почему реализация - это приход? Отвечает: "Реализация - это поступление выручки - т.е. данные берем из таблицы приходов"
LLM отлично транслирует текст с одного языка в другой, но смысл текста может измениться, и нам ещё нужно научиться работать с данным инструментом в реальх задачах.
Некоторые популярные модели некорректно предлагают простейшие запросы: "Имеются таблицы приходов и расходов номенклатуры на складе, сформируй SQL расчета остатков на складе на указанную дату" - отличный вопрос для собеседования.
Не пора ли ФНС перейти от первобытно-бумажных электронных отчётов по отдельным показателям к единому цифровому отчёту по деятельности предприятия?
Все предприятия давно ведут баланс в едином электронно-цифровом виде Дт-Кт-Сумма-Аналитика. Однако, продолжают формировать сотню (бывших бумажных) электронных сводных отчетов со множеством контрольных сумм, для проверки корректности заполненных показателей. Налог 3 продолжает традицию создавать отдельный сценарий под каждый показатель отчётности.
Сколько можно было бы сократить человеко-часов, заменив сотню узко-специализированных сценариев обмена на один универсальный, который уже действует на каждом предприятии (Дт-Кт-Сумма-Аналитика).
Предложенный метод "Учётной системы" применяется для управления предприятиями. Объекты в справочнике участвуют в различных регистрах - состояниях (моделях). Вычисления в регистрах могут быть взаимосвязаны транзакциями. Такой подход победил ООП и не даёт разбить на микросервисы ERP системы.
ООП и микросервисы - это не про архитектуру, это про командную работу, в которой удобно за каждым микросервисом или объектом закрепить ответственного и давить на него, требуя рабочий код в рамках возложенной ответственности, глубоко не вникая в его потребности.
Учётная система - комплексный подход к оптимизации связей элеметов. Кажется не сложно продумать заранее:
Регистр состояний (перчатка новая, перчатка требует починки);
Регистр владения (какие перчатки какому герою принадлежат);
Регистр столкновения юнитов (для всех перчаток, мечей, кольчуг проверяется их пересечение в 3д модели);
Другие регистры.
В этом подходе взаимосвязанных регистров размывается ответственность. Должен появиться архитектор, которого будут клевать со всех сторон, но который сможет убедить участников проекта сохранять компромис между функциональностью и простотой архитектуры.
ВЫВОД1: Описанная проблема не архитектурная, а организационная. Когда в команде распределяетя работа:
Начинающие разобьются на независимые объекты;
Опытные уже думают о группах сервисов состояний объектов;
Прожаренные смогут возглавить разработку по упрощённым шаблонам, не распыляясь на детализацию.
ВЫВОД2: Любой шаблон - устаревшая архитектура. Придет однажды новичек с новым объектом, сломает шаблон и все начнется сначала.
Пример про иерархию привел только как пример первостепенной, но не изученной области. Соответственно про простоту технологий говорить пока рано.
При изменении прав нагрузка будет - чтобы забрать полномочия.
К процессу выборки данных вопросов нет, смущает наличие функции в СУБД способной принять и переварить текст запроса с перечислением миллионов идентификаторов. При этом, с ростом объема данных размер текста запроса будет только увеличиваться.
Идеи инженеров-программистов не ограничены физическими законами, как у инженеров-конструкторов летательных аппаратов, но также регулярно разбиваются на реальных испытаниях.
Красиво, но не соответствует реальным потребностям:
Тысячи документов ассоциировать с правами для каждого пользователя - серьезная нагрузка. Особенно, если пользователь перешёл на новое место работы и все ранее выданные права необходимо пересмотреть по всем историческим документам;
Если у пользователя доступ предоставлен к миллиону документов, какого размера запрос отправится в СУБД чтобы показать список этих документов?
Подобные попытки спрятать логику в некую библиотеку разбиваются на реальных задачах. На сегодняшний день задача не решена и не имеет достаточной теоретической базы.
Например, задачу прав доступа нужно рассматривать со структуры предприятия, где права делегируются сверху-вниз, чтобы у подчинённого прав было не более чем у вышестоящего руководителя. А на практике, права руководителя собирают, как правило, снизу-вверх, админам проще дать права подчинённым, а руководителей включать во все возможные группы, или сделать одну супер группу, что тоже не упрощает раздачу прав.
PDCA не применим для управления предприятием. Это скорее индивидуальный процесс для сохранения своего KPI.
На предприятии цикл немного больше:
Разработка конструкции, технологии, нормирование операций;
Проектирование - выстраивание цепочки операций, назначение центров компетенции;
Календарное планирование, назначеие материально ответственных;
Расстановка приоритетов, резервирование ресурсов, запуск оптимальных партий по нескольким проектам;
Исполнение плана работ;
Контроль качества, сроков, технологии;
Упрощение его у всякого рода "консультантов" до План-Факт-Контроль-Корректировка приводит к рождению неполноценных автоматизированных систем, которые внедряются "авторитетными" подрядчиками, подсаживая предприятия на бесконечную поддежку и доработку...
Сверх меры никогда, только необходимое в рамках прикладного решения...
И тут мы будем долго стоять на своем, решая задачу каждый своим методом.
На фронте можно ещё проще, это же не многопользовательский режим. В рамках одной формы на каждый клик кнопки, на каждое изменение реквизита форма собирает со всех кортеж значений, обрабатывает скриптом-обработчиком (на любом языке) из нажатого компонента и рассылает всем результат в виде нового кортежа значений.
В свое время ООП тоже пытались применить для работы с базами данных от задач потребителя. Как объекты предметной области рисовали, так и API для бэкенда предлагали реализовывать. Код был прекрасен с точки зрения тестов и поддержки. Но не работал эффективно с точки зрения производительности на больших массивах данных.
С точки зрения пользователя удобно рассчитать зарплату каждому сотруднику индивидуально, загружая из хранилища только необходимые данные. А с точки зрения машины на несколько порядко быстрее, если зарплату всем сотрудникам рассчитывать в потоке, предварительно загрузив требуемые данные в буфер.
Борьба между удобством пользователя и производительностью машины бесконечна. Где-то, благодаря поднявшейся производительности машины, мы позволили себе создать удобные функции, классы, интерфейсы. Но возрастающее количество обрабатываемых данных продолжает давить на разработчиков, наши заранее продуманные простые функции и классы снова превращаются в сборище исключений, пометок о техническом долге, пропущенных тестах. Иначе задачи бы не сдавались бы в прод, а мы бы остались вечными студентами в поисках чистого кода.
Принцип "Все является файлом" однажды всё-таки должен быть заменен на "Все является элементом структуры", где для каждого элемента присваивается совокупность идентификаторов и имён, например
{id int, code case_sensitive string, full_name case_insensitiv string}, где:
id - индекс внутри среды исполнения
code - человеко-ориентированный регистрозависимый идентификатор, не меняющийся при копировании между средами (системами) исполнения (хранения)
full_name - регистронезависимое отображаемое для пользователя имя элемента
Командная строка, пути к файлам с такими структурами может усложниться превратившись в подобие json. Конечно, в этом случае ОС с клавиатуры админить напрямую не получиться. Но ведь появился ИИ, который любой текст при наличии словаря легко преобразует в json, командная строка легко возродится в новом качестве.
Уже парочка популярных СУБД есть, но в них нет RLS :-). А вот у Postgres есть PAM, есть статьи, как все связать вместе. Есть ещё неожиданный пример - в платформе 1с реализовали и RLS, и OpenID. Так что направление и тут развивается, был бы спрос.
Непонятно какую пользователю присвоить роль, а ролям назначит политику rls? Это творческий процесс, зависит от самой задачи.
Передача пароля - совсем уже примитив по сегодняшним технологиям. Рассмотрите как работает Kerberos или OpenID. Это не простые решения по администрированию, но важные подходы для любых систем.
Никогда, слышите, никогда не привязывайте правила RLS к пользователю напрямую (исключение только для его личных, не относящихся к профессиональной деятельности сообщений).
Скрытый текст
Надеюсь, когда нибудь появится время, влезу в исходный код ядра популярной ОС, чтобы изьять все права на файлы для Owner, обесценивающие все труды по настройке прав по группам пользователей.
Правила RLS привязываются к ролям (группам) пользователей. Все действия пользователь должен совершать в рамках своих ролей в системе. Если это система управления предприятием, то роли совпадают со штатным расписанием предприятия - работники приходят и уходят, а правила доступа остаются неизменными (если не меняются полномочия в самом штатном расписании).
Сопоставление и настройка правил доступа между ролями пользователей и объектами данных - это всегда трудный творческий процесс, независимо от уровня реализации - на уровне интерфейса, сервера приложений или сервера СУБД.
А какие ещё проблемы бывают? Пользователь зашёл под своими правами, делает в любом случае что хочет в рамках выданных прав, хоть БД удаляет, если ему такие права даны, как с инъекциями, так и без. Или чего-то ещё?
CTE - это и есть организация структуры запроса. На производительность не влияет, производительность сильнее просаживается, как только данные с носителя начинают читаться. Дополнительно оптимизатор корректно запрос оптимизирует, видя статические данные из СТЕ. Совокупность OR и AND конечно накладные расходы, но выглядит не хуже if или case, когда запрос по двум языкам размазан и для его тестирования в консоле нужно очистить от всех этих накладок
Я несколько о другом, я про LOW-CODE + SQL в котором аналитик сам прикладное решение создаёт, без программиста. Правда полноценных таких решений пока нет. Но мы же обсуждаем противостояния подходов, следовательно косвенно влияем на приоритеты для выбора разработчиков будущих решений.
Решениe 1. Включить авторизацию на уровне СУБД, настроить доступ, в т.ч. RLS - тогда пользователь будет делать только то, что позволено. Проблема пока ещё в отсутствии нормальной методологии (культуры) формирования структуры ролей и прав доступа, непроизводительная реализация RLS, но постепенно к разработчикам СУБД понимание приходит.
Решение 2. Параметризованные запросы - зло с точки зрения дизайна sql. SQL имеет на выходе набор(ы) данных. На вход ему также удобно подавать набор данных, к которому обращаться как к таблице, без всяких многочисленных вставок параметров в разных местах запроса. Такого интерфейса СУБД пока не имеют, поэтому как универсальное решение, упаковывать параметры и значения в json далее распаривать их в CTE как табличку из json с одной записью и использовать в разных местах. Вредоносные sql инъекции съедятся на этапе упаковки в json, конечно при условии корректной (один раз) отработки передачи json строки в качестве параметра.
Если параметры раскидывать по SQL, конечно, такой код не читабельный. Все параметры удобно описать вначале в СТЕ (WITH...) затем использовать в запросе, на скорость выполнения запроса критически не повлияет
Пример может показаться перегруженным, но это реальный шаблон помогающий для написания больших, сложных запросов.
Как-то аналитик быстрее понимает SQL, чем ORM. Поэтому LOW-CODE + SQL, а ORM пусть покурит в сторонке.
Можно по косвенным признакам определить, что крупные предприятия пока ещё не вкусили полноценных «ЕРП», успешные внедрения были либо в какой узкой специализации, либо поверхностные:
1. «ЕРП» еще не решали методические и технические проблемы разделения прав доступа. Сотня бизнес ролей должны быть завязаны по доступу на тысячи таблиц в БД. Текущие реализации RLS кладут производительность систем. Единственный удовлетворяющий по производительности RLS реализован в ORCLE – выглядит как «на коленках» собранное решение в котором текстовые строки сгенерированные админом тупо подставляются в каждый sql. Но даже при имеющихся технических решениях отсутствуют обсуждения проблем делегирования прав сверху вниз или проблем предоставления пользователю одновременного доступа к таблице на чтение и запись в зависимости от контекста записи (кладовщик должен редактировать накладные оформляемые на его склада, читать накладные направляемые ему на склад, к другим накладным он не должен иметь доступ).
2. «ЕРП» не кушали электронный технологический состав изделия из PLM. На крупных предприятиях конструкторская «Деталь» в технологическом составе одновременно может быть получена разными маршрутами, например отлита, вырезана на фрезере или приобретена у стороннего поставщика, В этом случае в технологическом составе PLM появляются новые объекты «Деталь литая», «Деталь вырезанная» и «Деталь покупная». Производить нужно по маршруту технологическую деталь а на промежуточный склад должна поступить конструкторская «Деталь». Какая «ЕРП» учитывает такие особенности?
3. «ЕРП» не охватывают всю хозяйственную деятельность предприятия, отгрызают только какие-то островки для автоматизации. При полном охвате деятельности, естественным результатом будет выдача выходного пособия для всех бухгалтеров, т.к. расчет стоимости становится по истине автоматизирован, для расчета прибыли и убытков остаётся только формировать общий расчет бухгалтерских проводок в конце отчётного периода. 1С, известная своими бухгалтерскими решениями, попыталась реализовать такой сценарий в своей «ЕРП» – оставить в должности только Главного бухгалтера для нажимания один раз в месяц кнопки закрытия периода. Первый блин, как говорится, оказался «комом», настройка всех справочников, да и сами реализованные процессы вызывают много вопросов. Это только показывает, что по настоящему автоматизированные системы управления крупными предприятиями у нас ещё впереди.
На моноколесе такого запаса инерции нет, оттолкнулся ногой, встал ею на подножку, надо сразу себя перебороть, ногами (телом) продавить педали (газовать).
Стоять без движения на моноколесе, как на двухколесном гироскуторе, тоже не получится.
Главное отличие моноколеса — само оно не катится. Обучение через «оттолкнулся-поехал», как с самокатом, велосипедом, и т.п. здесь не работают, они в первую очередь и мешают.
В моноколесе главное — «газовать», хочешь удерживать равновесие, должен ехать, т.е постоянно давить на педаль — вперед, даже при повороте. Вырабатываешь этот инстинкт, дальше интуиция подскажет.