Удивительная однозвенка на MS SQL

    ... с объектной ориентированностью, сериализацией, reflection, полиморфизмом, визуальным программированием, no-code, блэкджеком и шлюхами - и это на MS SQL 6.5 1995 году!

    Знакомые с историей IT при слове "однозвенка" вспомнят dBase и Clipper. Однако, я расскажу об ERP однозвенке. Интерфейсная программа для этой ERP общалась с базой через несколько интерфейсных таблиц и несколько процедур. То есть фактически она является браузером, который за слой не считается. Да, это #ненормальное программирование, которое дало ряд уникальных свойств.

    Иногда ведь хочется ручку настройки повернуть до максимума и довести идею до абсурда логического завершения. Как говорили родители одному из героев фильма "О чем говорят мужчины, продолжение" - "Так ты дойдешь до черте-чего!", а он думал "Так уже хочется взять и дойти до этого черте-чего!".

    Система называлась Ultimа-S, она же Nexus. Судьба ее была незавидна - эта ERP делалась на продажу, а продаж не было. Что, впрочем, было естественно - мы, в том числе автор этих строк, не имели ни малейшего понятия о маркетинге и продажах. Зато я имел удовольствие развлечься за счет работодателя. Итак,

    Поехали

    Берем установочные скрипты и устанавливаем систему на MS SQL 2019. Правда, базу пришлось загнать в compatibility mode. Запускаем exe. Он, кстати, крошечный (мне пришлось найти ntwdblib.dll):

    и в памяти занимает примерно столько же, сколько Notepad:

    fg
    fg

    Запускаем nexus.exe, и открываем иерархию классов:

    При использовании возникает очень интересное чувство, которое я не испытывал со времен MS DOS. Многие операции отрабатывают мгновенно. Нет, реально мгновенно. В современных программах, даже WinForms (я уж не говорю про Web), код настолько тяжел, столько динамически отводит памяти и столько раз вызывает GC, что глаз замечает видимые задержки. Мы к ним привыкли и не замечаем. Но когда программа реально рисует окно после нажатия на клавишу за время одного фрейма экрана, то это удивляет. А когда-то, во времена MS DOS, это было нормально.

    Как это работает?

    Вся коммуникация с сервером происходит через несколько процедур и три (с небольшим) таблицы. Хочется раскрыть папку - вызываем процедуру, передавая id папки, а в результирующую таблицу сваливается список документов, которые там находятся. Причем клиента не интересует, как этот список получился.

    Делаем right click и хотим получить список свойств?

    Тоже через таблицу. Пользователь видит user friendly имена свойств, а еще у них есть системные id, среди которых - как правило 'view' (read only просмотр по умолчанию) и 'edit' (основное редактирование).

    Наконец, мы выбрали свойство и хотим посмотреть документ. Результат выдается через таблицу Detailed где есть id полей, значения (есть колонки для разных типов) и колонку форматирования. Это поле в первой букве содержит тип значения int, float, money, string, document (который на самом деле тоже int), а дальше название для человека и некие теги указывающие поведение, например: fширина^min=0^max=10.0

    Вас конечно заинтересовало, если таблицы для коммуникации общие, то как могут одновременно работать много клиентов? Все очень просто - у всех этих таблиц есть поле spid (=@@spid). А все клиенты открывают ровно одну коннекцию и используют только ее (да, такой дизайн был нормой). Никаких connection pools. Представляете как легко сделать пессимистичные блокировки - по spid вы точно знаете что клиент не отсох и даже с какого hostnamе он работает!

    Обычно клиент располагает поля сверху вниз, но для важных документов могут быть задизайнены красивые формы. И да, теперь языком дизайна был бы наверняка HTML, а языком сценариев (min^ max^ и полее сложные пересчетом totals) был бы JS.

    Объектная ориентированность

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

    При выполнении операции (раскрытия папки, получения свойств и отображения) вызываются процедуры с именами вида Class_operation_ID_, причем вначале идет волна 'pre' свойств, начиная от Doc к листьевому классу, а потом 'post', в обратном направлении, от листа к корню. Как правило, все свойства pre, а post полезен для удаления данных (удаления лучше делать обратном порядке, от detail таблиц к master).

    Для pre свойство очередного класса 'видит' что натворили классы под ним, поэтому может не просто добавить поле или свойство, но и 'надругаться' над тем, что сделано до него - переименовать свойство или вообще убрать его, сделать поля read-only, дать им умолчания или вообще скрыть поля с помощью специального флага (но не удалять - иначе будут проблемы при записи)

    Ниже вы видите пример процедур на SQL, к которому был прикручен самописный макроязык. Обратите внимание как производный класс изменяет friendly name свойства пользователя, а также иногда добавляет новое свойство.

    Работа через Detailed давала еще одну интересную возможность: сериализация. Ведь можно просто вызывать свойство view (например), получить ответ, и запомнить его. Получалась мертвая копия, ксерокс, но выглядела она как настоящий документ - только была read-only.

    Аналогично, Аудит (история изменений) работала на уровне корневого класса Doc, сравнивая Detailed до и после редактирования. Все производные классы были освобождены от необходимости следить за аудитом редактирования!

    No-code

    Система позволяла мастерить новые документы прямо через интерфейс. Сейчас покажу пример. Создадим класс, производный от пользователя:

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

    Теперь через right click на образовавшемся классе создадим расширение, то есть новое поле - число пальцев от 5 до 10.

    Теперь мы создаем сотрудника, указав число пальцев 5, и записываем его.

    Посмотрим на результат. Новое поле добавилось внизу:

    Сравним обычного пользователя и VIP пользователя. Благодаря полиморфизму (в одной папке могут быть документы любого типа) мы можем положить в папку и обычного пользователя и VIP:

    С помощью No-code можно было создать сложные документы, с таблицами в духе товар-количество-цена и полем общая сумма, которая пересчитывалась автоматически - и это все без единой строчки кода. Данные ('расширения'), правда, хранились в универсальной таблице, что плохо с точки зрения производительности. Поэтому такие вещи предназначались для маленьких дополнений, а основной код все-таки писался на TSQL

    Вершиной no-code был user assistant - метод переопределения поведения любых полей.

    Администратор мог для любого документа, для любого поля, для определенной группы пользователей добавить умолчание, сделать поле read-only (что вместе с умолчанием заставляет использовать только определенное значение), или спрятать поле вовсе. Для полей выбора документов можно было изменить Root (папку начиная с которой выбираются документы для ввода) - например, пусть Вася Пупкин при создании платежки сможет указывать только этих трех клиентов (накидаем ссылки на этих клиентов в отдельную папочку)

    Фильтрация

    В системе были как обычный папки, похожие на папки для файлов, куда можно было перетаскивать документы мышкой, так и пользовательские фильтры:

    Через систему событий опрашивались все классы - а по каким полям ты умеешь фильтроваться?

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

    Заключение

    С тех пор я не видел потенциально более гибких систем. А монстры типа SAP R/3 живут и процветают...

    Реклама
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее

    Комментарии 40

      +3
      Вот так смотришь на это все…

      И понимаешь, что все-таки 1С свернула не туда!
        0

        Тонкий клиент 1С целиком и полностью копирует основную идею ultima or nexus резалтсет запроса хранить на сервере. Правда при этом программирование усложняется на порядок так как необходимо обеспечивать разделение программного текста на серверный и клиентский. Кстати через nexus можно совершенно спокойно рассматривать метаданные 1с или любых других mssql систем. У меня был опыт сопровождения биллинговой системы BillOnLine, в которую я внедрил nexus скрипт и тем самым обеспечил альтернативный интерфейс над таблицами системы. В силу того, что зачастую в современных системах база рассматривается как набор таблиц, хранящих данные и не более, а nexus работает с хранимыми процедурами, то на сегодняшний момент nexus — это единственная технология внедрения в любую учетную систему на базе mssql. Это я проделывал с базами DocsVision and 1C. возврат к Nexus обязательно произойдет., имхо.

        +1
        Справедливости ради, продажи были, но их оказалось недостаточно.
        Существовал (и вроде даже как-то дышит до сих пор) концептуальный аналог нашей Ультимы — это "БОСС-Компания" (не путать с «БОСС-Корпорацией»)
          +1
          Какое же всё раньше было маленькое и шустрое
            +2
            С тех пор я не видел потенциально более гибких систем.

            Сделать гибкую систему, внезапно, не так сложно, как сделать поддерживаемую и масштабируемую.

              +2
              Это, кстати, полезное наблюдение…

              Гибкость обычно приводит в восторг технических специалистов, поскольку позволяет менять систему под пожелания бизнеса, без переписывания кода. Однако у гибкости есть обратная сторона: часто, когда сделать можно «как угодно» до конечного пользователя доходит продукт, где не сделано никак. Т.е. типа с посылом «делайте, как вам больше нравится». А вот для конечного пользователя часто больше одного варианта (желательно строго прописанного в соответствующей должностной инструкции) — ни разу не плюс! Пользователь на предложение ему свободы действий впадает в ступор… Не каждый, но большинство. Просто потому, что в современную систему часто уже на уровне интерфейса заложены некие best practices, без которых человек сам не знает что ему нужно и как правильно…
                0

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

                  0

                  Ну, я надеюсь, мы с вами правильно друг-друга поняли. ;)


                  Потому, что мне-то как раз ваша разработка, в силу ряда можно сказать «личных» причин, очень понравилась! ;) Но имея опыт внедрения как раз максимально гибких самописных решений как раз столкнулся с выше описанными сложностями. Оказалось, что пользователям не надо гибко — им надо «напишите инструкцию куда нажимать». А внедренцев в костюмах у меня тоже не было....

                    –1

                    Есть небольшое отличие точки зрения автора от моей. Автор рассматривает nexus, как нечто прошлое. Я же рассматриваю его, как будущее. Может быть далекое, но будущее. Потому что вижу дорогу, по которой надо идти. Например, если привязать @@spid к схеме, то получится отличное разделение индивидуального от общественного. Каждый пользователь работает в своей схеме и со своими таблицами detailed etc. Процесс обобществления, конечно, есть. Но, это отдельная тема. Работа выполняется через слой view, которые несут в себе нагрузку метаданных для разных языков "человеков". Я уже не говорю про поисковые возможности класса иерархий без перемещения инфы в таблицах. Конечно, непривычно и на первых порах сложно, но это путь не к учетной системе, а прототипу искусственного интеллекта, который не есть чтото центральное и всеобъемлющее, а компактное. То есть nexus клиент + локальная база, к которой, если надо может подключиться другой клиент. Это путь к автоклассификации объектов с последовательным усложнением их свойств и поведенческих процедур.

                  +1

                  Это основной плюс nexus — он масштабируем. Поддерживать его действительно трудно поскольку в исходном варианте требуется вручную писать sql скрипты и полностью отсутствует работа с метаданными. Первое, что я сделал — это написал класс по генерации простого класса, потом класса посложнее, потом класса по выполнению динамического sql запроса. На самом деле надо писать полноценный конфигуратор, как в 1С. Поддержка — это всегда программист. Например, я — 1С программист. И чем я занимаюсь? По большому счету пишу код, который в конечном счете превращается в sql запрос. И чем мощее этот запрос, тем эффективнее код. Nexus работает с sql кодом только, и других программистов, кроме sql не надо. Вот в чем основная фишка. Все программисты и их технологии тоже, работающие на сервер приложений, в принципе не нужны.

                    –3
                    Это основной плюс nexus — он масштабируем.

                    Что вы понимаете под масштабируемостью? Для меня это способность обслуживать растущее число запросов ценой разумного (в идеале — не более чем линейного) роста ресурсов.


                    Ну и заодно (и это коррелирует с поддерживаемостью) — способность обслуживать растущую фукнциональность ценой сублинейного роста числа разработчиков.


                    Nexus работает с sql кодом только, и других программистов, кроме sql не надо. Вот в чем основная фишка.

                    Ну, для вас это, видимо, "фишка", а для меня — жирный крест.

                      0
                      То есть Вы не используете SQL? Сервер приложений — это большой ресурс. Вы его приобрели дополнительно, а теперь начали линейно экономить?
                        0
                        То есть Вы не используете SQL?

                        Не всегда.


                        Сервер приложений — это большой ресурс. Вы его приобрели дополнительно, а теперь начали линейно экономить?

                        Сервер БД я тоже экономлю, как ни странно.


                        Впрочем, у меня есть более занятный вопрос: а как, собственно, сделать из nexus веб-приложение?

                          0
                          Впрочем, у меня есть более занятный вопрос: а как, собственно, сделать из nexus веб-приложение?


                          да, если делать это сейчас (с нуля, разумеется), то система должна была бы поддерживать как WinForms клиента так и Web. Некоторые фичи (pessimistive locks) не очень совместимы с web, ну и бог с ними

                          А вот как архитектурно — очень интересный вопрос.
                            0
                            На данный момент никак. Он написан на С++. На самом деле он тонкий клиент или браузер в рамках базы данных и все хранит на сервере баз данных. Нагрузка сервера БД зависит от запросов и их количества. В чем же экономия, если запросы верные и оптимизированы?
                              0
                              В чем же экономия, если запросы верные и оптимизированы?

                              Экономию сюда принесли вы. А я спросил про масштабируемость. Во сколько раз надо увеличить серверные ресурсы, если число пользователей увеличилось в 1000 раз (при этом нагрузка, производимая одним пользователем, осталась неизменной)?

                                +2
                                Ни во сколько. Процессоры сервера всегда не дорабатывают или просто простаивают. Распараллель (запуск в отдельных фоновых процессах) вот и будет счастье. MIMD рулит в рамках sql.
                                  –2
                                  Ни во сколько.

                                  Если ни во сколько, значит изначально ваш сервер был в 1000 раз более мощным, чем нужно для решения задачи, и это неэкономно.


                                  Нет, мы исходим из того, что изначально сервер подобран так, чтобы выполнять прогнозируемую нагрузку с приблизительно 80% загрузкой ресурсов.


                                  Процессоры сервера всегда не дорабатывают или просто простаивают.

                                  Это значит, что ваша система изначально неэффективна.

                                    0
                                    Я както такими вопросами не парюсь. Есть сервер, который куплен априори. Я его могу загрузить и на 30 и на 90 и на все 100%, управляя количеством своих фоновых процессов. Я же пишу программу в конце концов. И только в последнем случае, когда сервер работает со 100% нагрузкой несколько дней подряд, я начинаю анализировать ботлнек. Зачастую, это неверный запрос, или ограничение дискового пространства. Если не нахожу, то эскалирую проблему выше на закупку новой техники. Где тут масштабирование?
                                      –1
                                      Я както такими вопросами не парюсь.

                                      Значит и масштабируемость вас не волнует.


                                      Если не нахожу, то эскалирую проблему выше на закупку новой техники. Где тут масштабирование?

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

                                        0
                                        В общем да, не волнует. Считаю этот момент коммерческим понятием, типа professional, enterprize, home, office для вытягивания денег с клиента. Смотришь клиент толстый — вот тебе полный пакет.
                                        Когда строишь дом, неважно какого размера, фундамент должен быть. Он, конечно, зависит от веса дома, почвы и пр. Но все это лишь параметры фундамента, а не какая-то фундаментальная характеристика «масштабируемость». Собственно, как и время, которую возвели в ранг чуть ли не измерения, а на самом деле, это всего лишь характеристика движения.
                                          –2
                                          В общем да, не волнует.

                                          Ну вот а других людей волнует, в этом и разница.

                                  0
                                  Ну обычно ERP системы все таки не фейсбук — даже WEB интерфейс будет выставлен, скорее всего, только в Intranet. Даже в большом кровавом энтерпрайзе число пользователей вряд ли привысит 1000, а одновременно активных — сотню. Так что вряд ли тут нужна какая то эластичность и фермы.

                                  К примеру, я имею удовольствие (точнее неудовольствие) работать с одной корпоративной системой ITSM, где каждый клик тупит секунд по пять — и ничего, не жужжат.

                                    0
                                    Ну обычно ERP системы все таки не фейсбук — даже WEB интерфейс будет выставлен, скорее всего, только в Intranet.

                                    Это когда как. Я знаю как минимум две ERP-системы, для которых облако — это основной способ развертывания, и это было очень важно в прошедшем году.


                                    Так что вряд ли тут нужна какая то эластичность и фермы.

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

                                0
                                Впрочем, у меня есть более занятный вопрос: а как, собственно, сделать из nexus веб-приложение?

                                Технически это несложно: вместо тонкого rich-клиента пишется аналог на JS + web server. Вместо прямого использования SPID в протоколе поддерживается сессия и делается проброс контекста в слой бизнес логики (session id -> SPID), метод описан в книжке "СУБД для программиста"
                                P.S. к «минусованию» ваших комментариев никакого отношения не имею
                                  0

                                  Кажется несложным, но немедленно вызывает следующие вопросы.


                                  Начнем с того, что надо сделать авторизацию. Раньше все было, как я понимаю, очень просто, и пользователь напрямую авторизовался в СУБД, а теперь так уже не выйдет.


                                  А во-вторых, теперь нужен веб-сервер, а веб-сервер — это тоже ресурс, и в этот момент распределение ресурсов и логики между СУБД и этим сервером становится занятным рассуждением.

                                    0
                                    Почему же не выйдет? Авторизацию можно по-прежнему продолжать использовать СУБД-шную, логин/пароль пробрасываются напрямую, сессия веб-приложения работает с установленным к СУБД соединением. Но возникает бонус — можно сделать и свою авторизацию поверх. Нужно ли это делать — отдельная тема.
                                    Вопрос был «как сделать веб-клиент?», вроде бы я ответил. Как сделать веб-клиент без веб-сервера не совсем понимаю. Сюжет о разделении нагрузки — другой вопрос, опять-таки, не вижу, что там нужно дополнительно разделять по сравнению с исходной архитектурой. Бонусы появляются, да.
                                      –1
                                      Почему же не выйдет? Авторизацию можно по-прежнему продолжать использовать СУБД-шную, логин/пароль пробрасываются напрямую

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


                                      (ну и заодно у авторизации-по-пользователю есть та проблема, что при определенном числе пользователей MS SQL просто говорит "больше нет", но это уже совсем отдельный разговор)


                                      Вопрос был «как сделать веб-клиент?», вроде бы я ответил.

                                      Понимаете ли, в чем дело, сам по себе ответ на этот вопрос весьма очевиден. Неочевидны следствия (часть из которых я описал выше), и которые и начинают потихоньку тыкать в те же самые места архитектуры, которые были озвучены как проблемные выше по треду. В частности, разделение нагрузки — это как повтор вопроса про разделение нагрузки между СУБД и прикладным сервером, про который уже выше написали, что плюс в том, что прикладной сервер вообще не нужен.

                                        0
                                        Зачем же гонять пароли открытым текстом? Веб-приложения давно умеют HTTPS. В любом случае, никакой специфики для данного случая здесь нет. Аналогично настраивается и SSO в Windows-сети.

                                        Рассматривайте архитектуру, не как отсутствие сервера приложений (СП), а как реализацию сервера приложений средствами СУБД, тогда большинство вопросов отпадает. Вопрос про распределение нагрузки решается аналогичным образом, как и в случае выделенного СП.
                                          0
                                          Зачем же гонять пароли открытым текстом? Веб-приложения давно умеют HTTPS.

                                          Затем, что HTTPS где-то заканчивается, пусть даже и на самом веб-сервере.


                                          Аналогично настраивается и SSO в Windows-сети.

                                          Не настраивается. Я пробовал, double-hop ломается приблизительно через раз.


                                          Рассматривайте архитектуру, не как отсутствие сервера приложений (СП), а как реализацию сервера приложений средствами СУБД, тогда большинство вопросов отпадает.

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


                                          Вопрос про распределение нагрузки решается аналогичным образом, как и в случае выделенного СП.

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

                                            0
                                            Замечание про дырки в цепочках TLS правильное, но, к сожалению, не специфичное для данной архитектуры. Вопрос неустойчивости SSO несколько субъективный, у меня был позитивный опыт (крупная supply chain система).
                                            Полностью с вами согласен, что масштабирование пары СУБД+СП имеет больше степеней свободы, чем СУБД со встроенным СП. Но как выше уже заметили, клиенту нужны не степени, а «чтобы работало по надежному сценарию, пусть даже одному».
                                            Разумеется, процедурное расширение SQL может показаться менее подходящим языком реализации бизнес-логики, тут есть и плюсы (встроенный интегрированный SQL, высокая производительность связанного с СУБД кода, отсутствие перегонки данных между процессами), так и минусы (как правило слабая организация модульности, СУБД vendor lock, отсутствие ООП, более сложное тестирование). Это все понятно, остается выбрать баланс соответствия конкретному случаю.
                                              0
                                              Замечание про дырки в цепочках TLS правильное, но, к сожалению, не специфичное для данной архитектуры.

                                              Для данной архитектуры специфично то, что ей нужен именно пароль. Не хэш, не токен — только и исключительно пароль, причем пароль от пользователя в БД.


                                              Вопрос неустойчивости SSO несколько субъективный, у меня был позитивный опыт (крупная supply chain система).

                                              Ваш опыт — он именно с "давайте залогиним пользователя в СУБД под той конкретной windows-учеткой, под которой он сейчас залогинен в браузере", или просто SSO?


                                              Но как выше уже заметили, клиенту нужны не степени, а «чтобы работало по надежному сценарию, пусть даже одному».

                                              Клиенты — они разные. Я как-то работал с клиентом, у которого изначальная система имела общие черты с описанной в посте. MS SQL, бизнес-логика в хранимых процедурах, сквозная авторизация windows-пользователя из толстого клиента в MS SQL. Все было неплохо, пока им не понадобилось дать доступ к этой же системе на два порядка большему числу пользователей снаружи организации (и, естественно, через web).


                                              Это все понятно, остается выбрать баланс соответствия конкретному случаю.

                                              Я был бы рад, если бы это действительно было "все понятно". Но опыт показывает, что не понятно.

                                                0
                                                Для данной архитектуры специфично то, что ей нужен именно пароль. Не хэш, не токен — только и исключительно пароль, причем пароль от пользователя в БД.

                                                Хмм… Представим себе типовое хранение хешей паролей в БД, проверкой которых занимается соответствующий сервис, напрямую соединяющийся с БД. Пусть длина цепочки передачи пароля до сервиса равна N. Теперь совместим сервис с СУБД. Длина цепочки остается N.
                                                Не забываем учесть необходимую дополнительную авторизацию самого сервиса в СУБД, получаем две цепочки уязвимости вместо одной.
                                                Ваш опыт сомнению не подлежит, но я бы не хотел переходить от обсуждений концептов к их реализациям.
                                                  0
                                                  Теперь совместим сервис с СУБД. Длина цепочки остается N.

                                                  Эээ. Вы предлагаете совместить веб-сервер с СУБД?


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

                                                  А как вы разделяете концепт и реализацию? Где вы проводите грань?


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

                                                    0
                                                    Просьба привести цитату где я предлагаю нечто подобное (хотя это технически несложно и давно реализовано в том же Оракле).
                                                    Обсуждаемый концепт реализован во множестве проектов «двухзвенок» с толстым клиентом, причем как концепт он обсуждался лет 20 назад.
                                                      0
                                                      Просьба привести цитату где я предлагаю нечто подобное

                                                      Вот здесь: "Теперь совместим сервис с СУБД. "


                                                      Обсуждаемый концепт

                                                      Какой конкретно концепт?

                                                        0
                                                        И зачем же вам нужен веб-сервер для доступа к авторизации уровня СУБД?
                                                          0

                                                          Мне нужен веб-сервер, чтобы сделать веб-приложение. Напомню, что мы находимся в треде "как сделать веб-приложение с таким же базовым подходом, как в статье".

                      +1
                      Может быть в то время программисты писали код, а не искали на stackoverflow как вызвать процедуру из фреймворка?

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

                      Самое читаемое