1Script.Web - создание модели базы данных. Таблицы, связи и сущности


#1

Представьте, что вы пишете приложение с базой данных. Но без 1С. Но вам хочется, чтобы было примерно похоже, с той же простотой.

Как бы вы задавали модель данных? Все что у вас есть - это Visual Studio Code и платформа, которая прочитает некий файл/скрипт/whatever и воспримет это, как модель базы данных…


#2

По мне так JSON, если читаемость будет не очень, то XML Schema.

А дальше "Новый ОбъектМетаданныхКонфигурация(“структура.json”) :smile:


#3

Я более детально имел в виду. JSON - это всего-лишь способ описания некоторого ИКС. А что внутри ИКС? Будет ли это один файл на базу, или много файлов, по одному на сущность? А может это будет код на os, а не декларативный файл?

Попробуйте представить, что вы создаете базу. Как выглядит идеальный процесс?


#4

На вскидку:

  1. Общий скрипт инициализации базы по файлам json
  2. Плагины для разных типов СУБД, тип и параметры подключения указываются в “заголовке” JSON.
  3. Несколько файлов JSON (в заголовке также указывается, что это JSON для инициализации СУБД)

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


#5

Я ровно про это спрашиваю: Как?


#6

Т.е. формат описать? Или чем их генерить?


#7

Думаю так

  1. отдельно файл с описанием создаваемой базы
  2. каталог с файлами описаний таблиц
  • Описание полей
  • Описание индексов
  • описание триггеров
  1. Каталог с описанием хранимок

#8

Как работать

  • При сборке обновлять схемы
  • в коде приложения все таблицы / методы доступны в отдельном неймспейсе (без необходимости дополнительно подключать)
  • запросы к базе должны быть на “БД-независимом” диалекте
    – как вариант предусмотреть подключение расширений для тонкой оптимизации

#9

@theshadowco

Поясни, что есть процесс сборки?

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

Свой или SQL-xx?


#10

Мне видится как некоторая функциональность движка, когда разработчик может сказать “мое приложение скомпилься / установись”, то по имеющимся настройкам базы происходит обновление схем.

Язык - я бы выбрал поддержку ansi SQL как базовую (дабы не придумывать), при необходимости подключая расширения других БД.
Зачем так: приложение может поддерживать хранение в любой СУБД, в зависимости от желания пользователя, тогда основная функциональность будет единой.


#11

Я вот тут тебе не совсем понял. Ты имеешь ввиду, что база уже есть и ты из нее вытягиваешь схему?

Тут, да, я выше про это тоже писал, про плагины.


#12

База может как быть, тогда надо вытяную ее схему и обновить, так и не существовать - тогда следовательно создать и настроить.


#13

Я любитель магии. Ты создаёшь класс, говоришь, что он реализует интерфейс/наследует класс/имеет аннотацию модели, над нужными свойствами аннотациями устанавливаешь типы и дополнительные необходимые свойства колонок таблицы.
Под каждую таблицу отдельный класс.
Все остальное берет на себя движок/либа. В когфигах указан способ подключения к субд. Стартуем приложение, выполняем метод инициализации и/или миграций, движок проверяет классы с аннотациями, создаёт/модифицирует таблицы, заливает их данными при необходимости (seed)


#14

Пока не забыл и не вылетело из головы @EvilBeaver

у меня есть мысли на этот счет, но они скажем так “визионерские”. Суть в том что у сущности есть несколько поведенческих моделей

  • CRUD
  • upgrade/downgrade
  • setStorage

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

  • сущность в зависимости от версии её схемы может улучшаться (появлятся новые реквизиты), ухудшатся (откатываться к обратному состоянию)

а с третьим вообще очень сложно, потому как инновационно.

  • сущность не обязательно должна хранится в sql базе - размышления привели к тому что хранилище сущности может быть

  • sql, nosql, fts (full text search), agregate

то есть что я имею ввиду

МодельРасходнойНакладной = Новый Модель("РасходнаяНакладаная);
МодельРасходнойНакладной.Версия(1);
МодельРасходнойНакладной.ИспользоватьХранилищеSQL(
   ТипыSQL.Postgres, ПодключенныеХранилища.ПолучитьПодключение("pg-prod-master")
);


МодельРасходнойНакладной.ИспользоватьХранилищеNOSQL(
   ТипыNOSQL.MongoDB, ПодключенныеХранилища.ПолучитьПодключение("mongo-master")
);


МодельРасходнойНакладной.ИспользоватьХранилищеFTS(
   ТипыFTS.Elastic, ПодключенныеХранилища.ПолучитьПодключение("elastic-master")
);


МодельРасходнойНакладной.ИспользоватьХранилищеАгрегатов(
   ТипыHOLAP.ClickHouse, ПодключенныеХранилища.ПолучитьПодключение("clickhouse-master")
);

Попытка
    МодельРасходнойНакладной.ИспользоватьКласс("src/model/РасходнаяНакладная.os")
Исключение
    ВызватьИсключение("Класс не соответствует определению модели: Подробно
    |" + ОписаниеОшибки())
КонецПопытки;

Фактически каждое хранилище для своего, что позволит очень долго не проваливатся в физику СУБД - оставаясь долго на уровне логики поведения модели :wink:


#15

Да, в целом так и есть. А еще можно вспомнить про модный CQRS