05.06.2016 16:42
hantenellotf 11 1700 Источник
В данной статье я предлагаю ознакомиться с идеей специфичной системы разработки. Система состоит из двух частей:
  • Особое строение базы для определения объектов и документов;
  • Внутренняя логика, управляющая базой и создающая набор функциональных модулей с определённой масштабируемостью;
  • Подсистема графического посредника между логикой и пользователем;
  • Подсистема дизайна, позволяющая создать интерфейс графического посредника.

Подробности под катом:

Дла начала нужно рассмотреть логику базы:
Строение базы:
image

Всё начинается с таблицы объектов (objects), в которой регистрируются единицы системы. Это справочники (Catalog), документы (Document), журналы (Journal), формы отчёта (Report), формы ввода / редактирования (Form) и скрипты (Script) для редактирования всех предыдущих или всей логики в целом.
Затем при создания объекта создаются таблицы: header_«objects.number» и data_«objects.number». В первой содержатся данные, характеризующие список данных: тип, наименование, ссылка на скрипт. Во — второй данные в пронумерованных столбцах по количеству элементов в таблице header_«objects.number». Ссылка состоит из двух частей: в header_«objects.number» сохраняется ссылка на объект (link_object) и ссылка на столбец (link_header). В таблице data_«objects.number» сохраняется индекс ячейки, на которую ссылается запись.
На следующем этапе я думаю создать набор процедур, обращающихся к базе на уровне objects: создание / редактирование, вставка данных и подтверждение операций. В данные процедуры я хочу сделать кодовые вставки, дабы на уровне объектов и стобцов проводить операции изменения данных (что актуально для журналов, документов и форм). Этими процедурами и вставками будет пользоваться подсистема графического посредника, которая отображает данные. Подсистема дизайна будет разрабатывать работу посредника и базы через логику.

Теперь вопросы:
  1. Насколько возможно реализовать эти уровни на языке Lua?
  2. Насколько перспективнее и легче в реализации просто создать оболочку разработки таблиц, нежели делать всё перечисленное выше?
  3. Насколько реально сделать функциональные вставки на уровне логики — графической подсистемы при такой схеме?
  4. Насколько функционально (в плане разбивки данных) и легче в чтении использовать одну таблицу столбцов (header), дополнительно указывая ссылку на объект?
  5. Насколько легче или сложнее проводить извлечение данных из этой системы? Не забьёт ли такая поправка базу?


Жду комментариев и советов.

P.S. По поводу функции prepare / bind в связке luasql — sqlite3 — нереализуема. Давно стоит ошибка на стаке и функции просто возвращают nil (http://stackoverflow.com/questions/32670262/prepared-statements-for-lua-with-luasql, http://stackoverflow.com/questions/16176833/prepared-statements-in-luasql-postgres). Посему только BEGIN… COMMIT через execute().
Поделиться с друзьями
-->

Комментарии (11)


  1. Delphinum
    05.06.2016 20:01
    #9644268
    +1

    Ну во-первых — тостер.
    Во-вторых — как то слабо вы изложили свою мысль, лично я практически ничего не понял из вашей идеи, но если я понял правильно, то такого рода «конструкторов» хватает. Да практически любая современная и устаревшая СУБД сопровождается механизмами для построения UI и отчетов. Есть и более сложные решение, которые позволяют не просто создавать объекты и документы, а разрабатывать полноценное бизнес-приложение, взять ту же платформу CUBA и прилагаемую к ней CUBA-Studio.


    1. amaksr
      05.06.2016 21:18
      #9644308

      Из статьи я тоже не понял только лишь всё… Пошел по вашей ссылке, скачал CUBA, с удивлением обнаружил, что у меня тоже есть похожий самописный велосипед. Правда он берёт за изначальные данные структуру БД из операторов CREATE TABLE, не умеет генерировать UI, но зато генерирует код классов и типовых операций над ними на разных языках.
      Осталось только выяснить, об этом ли была статья…


      1. Delphinum
        05.06.2016 21:25
        #9644314

        но зато генерирует код классов и типовых операций над ними

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


        1. amaksr
          05.06.2016 22:00
          #9644330

          Под типовыми операциями я имел ввиду прежде всего клонирование, и для разных языков. Например пусть есть такой объект:


          CREATE TABLE emp (
    id INT,
    name VARCHAR(64),
    hire_date DATETEIME
)

          Для него клонирование (а так же конструирование объектов и JSON-ов) на Javascript должно учесть, что дату лучше клонировать оператором new:


          var Emp = function(old) {
    this.id = old.id;
    this.name = old.name;
    this.hire_date = new Date(old.hire_date);
}

          Так же, не думаю, что CUBA умеет генерировать код для MySQL для STORED PROCEDURES. Что-нибудь типа такого:


          %%DECLARE(EMP_REC_, emp)

          которое бы автоматически развертывалось в


          DECLARE EMP_REC_id INT;
DECLARE EMP_REC_name VARCHAR(64);
DECLARE EMP_REC_hire_date DATETIME;

          Ну и по тому же принципу:


          SELECT * INTO %%INTO(EMP_REC_,emp) FROM emp ...;

          развертывалось бы в


          SELECT * INTO EMP_REC_id, EMP_REC_name, EMP_REC_hire_date FROM emp ...;

          Ну и плюс до кучи мой велосипед генерирует код PHP, в частности классы для Laravel со всеми setter-ами и getter-ами и доступом к связанным данным по Foreign Keys.


          1. Delphinum
            05.06.2016 22:08
            #9644336

            CUBA это Java фреймворк, ориентированный на PostgreSQL и MS SQL. В нем предлагается своя архитектура.


      1. gimntut
        05.06.2016 23:16
        #9644372
        +1

        Мне кажется, что я понял о чём статья. По сути автор придумывает свою 1с, с платформой (графический посредник) и конфигуратором (подсистема дизайна). Даже таблицы объектов такие же: справочники, документы, отчёты. Только вместо языка 1с предлагается lua, а вместо файловой базы — sqlite.
        Я считаю, даже если всё описанное в «статье» будет реализовано, то этого будет мало. Современному программисту нужны инструменты отладки, механизмы тестирования, версионирование и развертывание.
        Зачем мне скриптовый язык, если я не могу его отлаживать?
        Как я могу быть уверен, что после внесения нового функционала у пользователя что-нибудь не сломается, если код не покрыт тестами?
        Как я могу вернуться к старому коду или посмотреть, что сломало мой код, если нет версионирования?
        Даст ли мне среда разработки возможность экспериментировать с кодом не мешая пользователям?
        Насколько просто можно влить изменения или отменить их на серверах пользователей и их рабочих станциях?

        Вот из-за таких вопросов, в дополнение и даже на замену таким зрелым инструментам как конфигуратор 1с приходят инструменты подобные 1с:Enterprise Development Tools
        habrahabr.ru/company/infostart/blog/255757
        А автор решил пройти весь этот путь в одиночку.


        1. hantenellotf
          06.06.2016 06:26
          #9644466
          -2

          1. Теперь можно расписать подробнее вопросы версионирования и отладки? Отладка должна проводиться на тестовой конфигурации с тестовым набором данных и компонентов, в ходе теста приводящие к ошибке / крашу. Я правильно понимаю? И зачем версионирование для заранее составленной системы сценариев? И что мне, кстати, мешает сохранить предыдущую объектную структуру и просто изменить набор управляющих скриптов?
          2. 1С хоть и хорошая система для среднего и крупного бизнеса (взято со знаком вопроса, учитывая мой опыт сисадминства этих радостей), для частного бизнеса приятнее использовать программы по системе «упрощёнка» (и дешевле в раз 40). Ибо элементарный учёт ещё никто не отменял.
          3. Я желаю пройти путь по созданию Micro ERP системы разработки и создать оболочку для «упрощёнки». Для изучения технических вопросов разработки был написан предыдущий цикл статей.
          4. По последнему комментарию — 1С создаёт собственную структуру баз под каждую конфигурацию. Если вы откроете базу конфигурации «Склад» и «Бухгалтерия» вы увидите совершенно разные таблицы и список совпадающих будет минимален. Совпадающими будут куски из конфигураций и взаимозависимые табличные части для взаимодействующих или гибридных конфигураций («УНФ», «Предприятие») Фактически, под каждую конфигурацию пишется своя собственная конфигурация баз.
          5. Я же предлагаю перевести мета — описание данных в данные для другой мета — структуры. Фактически, я предлагаю сделать железобетонное расширяемое мета — описание, в котором отображается структура достура к данным и есть возможность быстрого изменения шапок без удаления самой информации. И модификации данных без изменения мета — структуры базы.

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

          P.S. Мало кто из вышеотписавшихся смог понять структуру объекта и никто не смог ответить на предложенные мной вопросы. Жаль, но придётся этот путь действительно проходить самому, без чьей-либо профессиональной поддержки.


  1. hantenellotf
    06.06.2016 06:38
    #9644472

    P.S.S. Мне нужны развёрнутые, а не быстрые ответы, потому «Тостер» отпадает.


    1. Lertmind
      06.06.2016 07:17
      #9644492
      +1

      На хабре — статьи, на тостере — вопросы. Либо ищете специальные форумы. Уже не в первый раз такое. Почему так сложно понять?


      1. hantenellotf
        06.06.2016 07:20
        #9644494
        -1

        1) Это не прописанно в Ваших правилах.
        2) Мне нужны подробные комментарии, а не отмазки.


        1. DrPass
          06.06.2016 09:52
          #9644564

          > 2) Мне нужны подробные комментарии, а не отмазки.
          Ну это же ваша тема, удалите тут всех, кто пишет недостаточно подробные комментарии.