JSON "язык" запросов к объектам #785536

Как понимаем появление "языка запросов 1С" (как некой копии с дополнениями стандартного SQL) это вынужденная мера для предметно ориентированной системы, которая является подмножеством объектно-ориентированной. Ибо данные то хранятся в обычных реляционных БД и приходится проецировать метаданные (объекты) в таблицы/записи. Отсюда вариация обычного SQL становится самой быстрой, банальная трансляция из "языка запросов 1С" в стандартный диалект SQL конкретной базы данных и все зависит от ее скорости. Но вот изобретая лисапед пришел к выводу что SQL подобный язык для объектов не нужен, нужно нечто другое которое позволит выполнять аналогичную задачу но с более удобной записью. Понятно что это в случае не использования обычных реляционных БД а простых хранилищ документов или значений. Нашел несколько теории И даже нечто работающее , но это просто обертка над SQL стандартным. По сути хочется описал в JSON результирующий требуемый объект или объекты которые хочется получить, например выборка "остатки на складах": [{"Номенклатура":"Справочники.Номенклатура","Остаток":"Число"}] Далее указать для свойств этого результирующего объекта откуда брать данные и как их соединять (операции над множествами): "Источники":["Справочники.Номенклатура","РегистрыНакопления.Остатки"], "Операция":"Объединение", "Условия":["Остаток>10","Номенклатура.Группа=&Параметр1"] И получить результат в виде множества новых или существующих "объектов". Кто видел/знает подобное или может занимался таким извратом? Смысл что хочу максимальное упрощение для "программиста" составления "запросов" на подобном "языке", но с сохранением гибкости и мощности обычного SQL. Ибо сложные вложенные составные/вложенные запросы на "языке запросов 1С" когда они много строчек разбирать без конструктора нереально сложно. Тут же более наглядно будет видна вложенность и последовательность выполнения операций.

Как понимаем появление "языка запросов 1С" (как некой копии с дополнениями стандартного SQL) это вынужденная мера для предметно ориентированной системы, которая является подмножеством объектно-ориентированной. Ибо данные то хранятся в обычных реляционных БД и приходится проецировать метаданные (объекты) в таблицы/записи. Отсюда вариация обычного SQL становится самой быстрой, банальная трансляция из "языка запросов 1С" в стандартный диалект SQL конкретной базы данных и все зависит от ее скорости. Но вот изобретая лисапед пришел к выводу что SQL подобный язык для объектов не нужен, нужно нечто другое которое позволит выполнять аналогичную задачу но с более удобной записью. Понятно что это в случае не использования обычных реляционных БД а простых хранилищ документов или значений. Нашел несколько теории И даже нечто работающее , но это просто обертка над SQL стандартным. По сути хочется описал в JSON результирующий требуемый объект или объекты которые хочется получить, например выборка "остатки на складах": [{"Номенклатура":"Справочники.Номенклатура","Остаток":"Число"}] Далее указать для свойств этого результирующего объекта откуда брать данные и как их соединять (операции над множествами): "Источники":["Справочники.Номенклатура","РегистрыНакопления.Остатки"], "Операция":"Объединение", "Условия":["Остаток>10","Номенклатура.Группа=&Параметр1"] И получить результат в виде множества новых или существующих "объектов". Кто видел/знает подобное или может занимался таким извратом? Смысл что хочу максимальное упрощение для "программиста" составления "запросов" на подобном "языке", но с сохранением гибкости и мощности обычного SQL. Ибо сложные вложенные составные/вложенные запросы на "языке запросов 1С" когда они много строчек разбирать без конструктора нереально сложно. Тут же более наглядно будет видна вложенность и последовательность выполнения операций.

+ Ошибся, правильнее "Операция":"Пересечение" ибо

Просто, объектно-ориетнированные базы данных не взлетели. А так - там можно было писать выборку прямо по объектам. Просто то, что ты пытаешься сделать - это некоторый аналог 1С 7.7 - там вместо SQL языка была придумана какая-то муть, позволяющая что-то отбирать и что-то указывать. В твоём примере пишется: SELECT FROM [Справочник.Номенклатура],[РегистрНакопления.Остатки]VALUES[Справочник.Номенклатура].[Ссылка],[РегистрНакопления.Остатки].Количество WHERE [Справочник.Номенклатура].Группа=&Параметр1 AND [РегистрНакопления.Остатки].Количество>10 AND [Справочник.Номенклатура].[Ссылка]=[РегистрНакопления.Остатки].[Номенклатура] То есть, в нормальном SQL есть такое понятие, как прямое произведение таблиц, что в 1С почему-то не вспоминают. В том же Microsoft Access именно так и писалось.

Да сразу про аналог "запросов 1С 7.7" тоже подумалось, но там урезали только выборка и соединение. По сути и хочу но запись не в одну строку (которую парсить сложнее чем JSON) а в неком другом более удобном виде, вот и все.

Тогда получится тот же самый SQL только записанный по-другому.

Гм действительно так (( "SELECT":{ "FROM":["Справочник.Номенклатура","РегистрНакопления.Остатки"], "VALUES":["Справочник.Номенклатура.Ссылка","РегистрНакопления.Остатки.Количество"], "WHERE":[...] ] }

Получается ничего лучше чем SQL банально не изобрести? Печально ((

И, по-мойму, это называется "конструирование уникальной модели колёсного средства передвижения приводимого в движение мускульной силой"

Угадал! Но ведь а хочется

Просто SQL с тех времён, когда была командная строка. Изобрести можно - функции-итераторы называется. Но, если с помощью SQL можно построить оптимальный запрос, так как условия могут выбираться по индексам, то итераторы - это полное сканирование, что не всегда оптимально. Просто, индекс можно рассматривать как кеш результатов итератора - тогда индексы будут динамическими и подстраиваться под задачи - но это, видимо, очень далёкое будущее.

То, что хочется - это самокат-электропед - как-то даже звучит не очень.

SQL прекрасен и не нуждается в улучшениях. Всякие ООБД придумывают гуманитарии, которые не смогли. А так то о тебе позаботилась фирма 1С, СКД вполне себе позволяет объектно конструировать запросы без всякого SQL. Конечно, это ересь, не нужная здравомыслящему человеку, но таки оно есть.

Кстати да, тоже приходило в голову про динамические индексы, которые сами по результатам запросов на лету строятся "на будущее". Нечто похожее на VIEW ) стандартные, которые автоматически обновляются при записи/изменении данных в исходных таблицах.

SQL прекрасен для реляционных БД обычных, но не для объектных с предметно-ориентированными.

Да СКД великая штука, но без "Набор данных - запрос" она уже не столь велика.

Конструктор SQL и ничего более.

Возникает вопрос, что понимать под объектной предметно-ориентированной БД? Если это настоящее nosql хранилище, то там sql попросту нет, приходится выкручиваться. А если это эмуляция каких-то там объектов и иерархии, например 1С, то sql там все равно удобнее. Оно умеет как-то программной схему запроса составлять, вообще ни одной строчки на языке запросов писать не надо. Еще в Построителе что-то подобное было, а тут это довели до логического конца. Получилось ожидаемо непонятно.

Опять же, взять к примеру тот же 1С. Мы хотим, чтобы у справочника "Номенклатура" появилось дополнительное поле - или открывать конфигуратор и добавлять его в таблицу с перестроением всей таблицы или добавлять через механизм, в который мы только что учили писать дятла - но там про быстрый поиск можно забыть. А если у нас объекты - то добавил поле - у новых объектов оно появилось, а у старых - значение по умолчанию.

Угу проблема что на изучение даже половины возможностей этого конструктора требуется просто дофига времени. В условиях когда спецов хрен найдешь понижение времени обучения (порога входа) становится актуальным. Сча спецы (именно спецы знающие/опытные) нарасхват, а новичков ("типа программист 1С") только много. И когда новичок банальную задачку решает на порядки (в десятки раз блин!) медленнее чем спец, а з/п то хочет всего в 2-3 раза меньше чем спец это тоскливо...

nosql - там обычно ключ=>значение. То есть, грубо говоря, от индексов отказались - и только прямое сканирование.

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

Ага подумал что при прямом сканировании можно язык запросов упростить офигенно. Точнее все сложные запросы будут состоять из кучи подзапросов с "В (&Список)"

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

Но проблема нормализации данных и соединений разных объектов.

+ там запросил итератор - и сказал "поддерживать" и вот вам индекс для выборки по итератору.

Так связь - это тоже объект. Плюс - история изменений - любое действие - это изменение объектов - предыдущие версии не стираются, а остаются - можно в любой момент увидеть то, что было когда-то.

Угу только вот в 1С "документ" это типа один объект, а по факту в БД это куча таблиц включая записи ТЧ - куча объектов. И при перепроведении документа придется или храним в ООБД документ как одно целое (читать целиком накладно) или кучу объектов "записей ТЧ" что будет накладно их перебор с отбором по полю-владельцу.

Просто, сейчас в базе есть таблицы, в которых ссылки на ключевые поля других таблиц. В объектной базе ссылки будут сразу на места, где хранятся объекты. То есть не нужно будет идти в следующую таблицу и читать значение полей объекта - мы уже сразу там.

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

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

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

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

Реструктуризация )) По сути если объект слишком большой то пишем его целиком в новое пустое место побольше (куда влезает с запасом), а старое помечаем как свободное. Блин TRIM на SSD...

Вот это огромный плюс, но каким образом запросы к этим сколь угодно?

Ещё, очень прикольная вещь - TRANSMUTE когда один объект преобразуется в другой, чего в таблицах сделать не так уж и просто.

+ Хотя вложенная ТЧ это же просто "объекты  -строки ТЧ" и "объекты - связи"

XSLT для JSON ?

В SQL и сейчас можно сколь угодно вложенные таблицы сделать. но в них будет составное ключевое поле или связь через идентификатора-посредника.

JsOn тоже не очень хорош - он не позволяет описывать графы. А любая база данных - это граф. Приходится вводить идентификаторы (как это сделано в SQL) и писать отдельные массивы (таблицы).

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

В реляционных БД без идентификаторов "id" тоже не выйдет граф описать

Сейчас, если ты отбираешь документы, в которых упоминается товар, находящийся в папке с определённым свойством, то ты просто строишь такую структуру в памяти.

Без id вообще не выйдет описать граф - просто в памяти вместо id идёт место размещения объекта - то есть его адрес. В pdf-файле можно так ссылаться на объекты, в нём записанные.

Логично

+ и как решается данная задача быстро - мы сначала отбираем товары с этим свойством во временную таблицу или массив, а потом ищем эти товары в документе. То есть прошлись итератором по товарам - получили результат, который стал итератором для документов. Просто, если много товаров и мало документов, то проще из документа смотреть в товар, а если мало товаров - то сначала отобрать товары и просеивать документы. А можно сразу - смотреть по документу и проверять товары, отбирая уже проверенные в массив со значениями да или нет.

Короче ждем квантовые компы с квантовыми БД и применяем ))

Потом ещё можно вспомнить про тени, представления и отражения, когда один объект для пользователя оказывается другим - и станет вообще очень интересно.

Отражения это "изменяемые представления"? А тени это что?

Кстати, в 1С есть некоторый аналог объектного подхода - когда мы через точку получаем значения полей объекта - система переносит нас из одного объекта в другой, причём объекты кешируются, чтобы каждый раз в базу не лазить. И неких аналог "отражения" тоже есть - ПредставлениеОбъекта. И просто объект с произвольными полями есть - Структура. А если вспомнить "Соответствие", то это ещё более интересная вещь, где поля могут быть объектами. Ну а TRANSMUTE мы используем, когда с помощью конвертации данных переносим их из одной базы в другую. Ничего не мешает эти правила использовать в одной базе.

Тени - это как раз и есть "замещение", когда вместо реального объекта пользователю показывается другой - в 1С показываться может только НЕОПРЕДЕЛЕНО или NULL если на что-то прав нет. Просто, например, все любят, чтобы менеджеры не видели чужих контрагентов, но вопрос, когда менеджер ищет по ИНН и не находит, никто не решает - а так - он будет видеть о контрагенте только то, что допустимо - то есть, например ИНН, чтобы не создавать дубль с тем же ИНН для себя, а использовать общий объект для своих нужд, просто меняя тень. Соответственно, если поля задаются как и у основного объекта - они будут просто "просветляться", а если нет, то использоваться замещение. Опять же - тень очень полезна, когда хочется посмотреть, как будет, если мы что-то поменяем - вместо изменения объекта - делаем тень и меняем всё, что хотим. Другими словами - тень - это отложенная транзакция изменений.

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

Да была у меня идея наваять КД для обычных реляционных БД, но потом понял что это будет простой конструктор запросов выбирающий данные из одной баз и insert|update в другую. Ага понял, когда вместо реального объекта показывается его "тень" - типа объект есть (видим что он есть и все, но использовать не можем)

Тень ещё позволяет к основному объекту довесить свойства, которые основному объекту не нужны, а пользователю очень хочется - чтобы в комментарий не писать текстом.

Гы если грохнуть справочник то можно оставить его "тень" в виде доп.реквизитов.

Ладно - надо идти спать - а то мечтать о чём-то несбыточном можно очень и очень долго. Просто отношение "тот, который" или ссылка на поле объекта очень бы спасла кучу народа от ошибок учёта.

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

Просто, был элемент справочника со всеми данными - и он был в выборе и искался по штрих-коду - удалили его из списка - всё он перестал отображаться в списке и перестал искаться по штрих-коду, но в документе, где он был - он остался. И волки сыты и овцы целы - а не как сейчас - битая ссылка или гора мусора в списке.

Всё - я спать. И пусть мне присниться другой мир, где все базы данных объекто-ориентированные.

Linq наше все

И, самый главный кошмар объектно-ориентированной среды, про который мы вчера забыли - это сборка мусора. Собственно, этот "большой минус" перечёркивает все остальные плюсы реализации.

Вы изобретаете nosql. Посмотрите как делаются запросы в той же монге.

Ну, после размышлений о уже ничего изобретать не хочется. Просто, mongoDB хранит объекты независимыми. А для удобства использования хотелось бы описания типов полей вынести в отдельное место, чтобы в каждый объект название поля и тип не писать. Также - длинные строки проще сразу бить на слова, чтобы полнотекстовый поиск работал - да и места они занимать будут меньше, если вместо слов будут ссылки на них. И индексы - нужны индексы, иначе всё это объектное чудо будет сравнимо только с улиткой или черепахой.

И вообще - объекто-ориентированная СУБД - это вот: Вообще, как бы, они написали ещё тогда более производительный аналог 1С.

что бы критиковать реляционные субд стоит для начала кратенько описать "нормализованные формы" и напротив каждого правила написать его плюсы и минусы и только после этого будет понятно чего именно тебе не хватает....

Тут ещё есть такой момент, что объекто-ориентированная СУБД тоже может быть реляционной, то есть к ней могут применяться те же самые запросы SQL. Если у нас построен индекс по каким-то полям объектов, то для поиска не столь уж и важно, как эти объекты хранятся - мы будем читать с диска  только те, которые упомянуты в индексе. А устройство индекса, по большому счёту, от того, как реально хранятся данные - не сильно меняется - в любом случае - получается дерево.

да это не важно, важно сначала понять 1. чего не устраивает в текущей теории и реализации 2. чего реально хочется изменить 3. и чем придётся пожертвовать ради этих изменений после ответа на эти 3 вопроса желание городить велосипед пропадет.... автор только частично затронул фантик от первого вопроса....

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

а аптека всё стоит

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

С регистрами только все плохо, особенно накопления.

Там вообще со всем всё плохо. В текущей системе - хранение (СУБД) отделена от алгоритма (сервер 1С). Если делать работу с объектами, то отделение просто не получается - а это - реализация СУБД практически с ноля. Как раз регистры-то ещё можно сделать, если разрешить у объектов иметь методы - тогда он вызывает метод "информация для обновления" и блоки накопления метятся как не посчитанные - когда они кому-то понадобятся, будет выполнен пересчёт - если сохраняется ещё и старое значение - то всё будет быстро и хорошо.

Ну если уж фирма 1С не осилила свою NoSQL базу данных написать :(

Вопрос не в "не осилила", а в параллельности работы. SQL-сервер позволяет выполнять обновление данных несколькими сеансами одновременно - там для этого специальные механизмы блокировок и транзакций придуманы. Никто не захотел всё это переписывать с нуля. Тем более, что в 1С в базе хранятся только объекты определённых заранее заданных типов.

У NoSQL  это прежде всего БД в памяти, но и у SQL тоже есть Таблицы, оптимизированные для памяти NoSQL обычно применяют для кэширования данных. Есть Данные JSON А, что есть в MS SQL 2016 в том числе и для Linux еще не смотрел, но EF это поддерживает

Так в итоге один фиг пришлось свою "параллельность" с управляемыми блокировками изобретать. По сути пошли по более простому традиционному пути, вместо изобретения лисапедов своих. Даже от тех что были зачатки в 77 отказались.

Как бы, в SQL-базах объекты обычно хранятся как JsOn или т.п. в BLOB-поле.

Смысл в том, что доступ к полям как к Json по аналогии с XML на стороне SQL. Кроме того можно получать данные в формате XML Что удобно для HTTP сервисов

Потом, работа с JsOn данными - это только полное сканирование. При малых объёмах достаточно удобно, чтобы думать, что у тебя SQL, а при больших - будет всё равно что таблица без индекса. Если строк в таблице меньше 1000, то как бы она не хранилась, никто торможения не заметит.

Ну это просто прикручивание к SQL-серверу возможности форматированного вывода данных запроса. Позволяет данные напрямую клиенту отсылать без какого-либо преобразования.

Есть подозрение что скоро все популярные движки БД де факто станут "гибридными" SQL+NoSQL в одной коробке.

При этом есть и For JSON Если тебе нужно удобно выдернуть данные из JSON или XML то индексы не нужны. Так оно и есть.

Это когда у тебя с клиента данные пришли в JsOn - понятно, что их выдёргивать нужно и другого пути, кроме полного сканирования нет - ведь в отправленных данных не может быть передано то, что не нужно.

Гм насколько на данный момент скорость (чтения/записи произвольной) оперативной памяти DDR3|DDR4 быстрее чем SSD? Просто если вспомнить "Архитектуру фон Неймана" то память 2 разных видов (оперативная и постоянная) не нужна совершенно. В результате если БД реализована только для одного "вида памяти" не лучше ли будет именно объектная база данных? В которой индексы это по сути абсолютно такие же стандартные объекты базы?

Индекс - это упорядоченный набор пар Ключ=>Значение, где значение - это указатель на основной объект.

Дык про что и речь, просто пишем адреса в памяти (общей) и все.

Реально - и в SQL-базе в индексы пишутся ссылки на страницы (считай адреса в памяти) где живут сами строки (считай объекты).

Просто, реально SQL-предполагает, что можно изменить только одно поле объекта, тогда как в случае хранения объекта в общем виде - изменение поля может приводить к изменению его размера и выходу за пределы блока памяти, отведённого под объект.

Используем особенность работы SSD на перезапись, где по сути всегда происходит чтение и запись в другие блоки при этом. Итого нужно NoSQL БД делать аппаратную на железе внутри контроллера SSD :)

Она там итак уже есть - просто ключ - это номер блока, а значение - данные. Понятно, что писать каждый раз объект нужно заново, и лучше в другое место, чтобы оставалась старая версия - тогда можно делать что-то типа изоляции транзакций, когда разные транзакции видят разные данные.

Красивую картинку нашел тут

Еще раз, JSON данные обрабатываются на сервере, аналогично как из поля выделяются данные.

+ По сути как только требуется распределенное хранение данных (на разных серверах/кластерах) то обычные реляционные базы кончаются в муках.

А что касается поиска (отбору), по JSON данным, то это другая песня.

Ничего не кончается. Смотри 73

> SQL подобный язык для объектов не нужен, нужно нечто другое которое позволит выполнять аналогичную задачу Да не дай бог жить в "это время прекрасное". Разные "современные" безумные ORM-конструкции или тот же семерошный синтаксис дохнут как мухи. А скуль живее всех живых. И это прекрасно, потому что скуль корректно отражает операции над множествами (реляции / отношения). Это все от ниасилятора математики, множеств, функций, отношений. > Ибо сложные вложенные составные/вложенные запросы на "языке запросов 1С" когда они много строчек разбирать без конструктора нереально сложно. Любой биоразложимый код разбирать нереально сложно. В любом языке программирования. > Тут же более наглядно будет видна вложенность и последовательность выполнения операций. Говн0код можно написать на любом языке. От писателя и окружения зависит, будет ли видна "вложенность и последовательность". Гораздо лучше вкладываться в обучение людей правильным структурам данных, алгоритмам, математике, кодированию и управлению сложностью систем. Новый ОЫЩТ-подобный язык / синтаксис никого не спасет.

Можно пример не отказоустойчивого кластера любого SQL сервера а ускоряющего быстродействие одной базы?

Т.е. прекрасно понимаем что раз для нынешнего "программиста 1С" де факто требуется изучить как минимум 2 различных языка программирования: "язык 1С" и "язык запросов 1С". Но когда не хватает мозгов получается изучают только один (язык запросов) и в результате ныне есть такие успешные "программисты 1С" которые даже сортировку ТЗ через запрос делают... Мое же предложение оставить обязательным только 1 язык, а "запросы" будут простым продолжением этого языка.

+ Причем отказа от "языка запросов 1С" не будет, просто они будут автоматически формироваться как в конструкторе "из кода".

Просто, если нужно распределёно хранить данные, то можно сделать несколько SQL-серверов, между которыми делить данные по какому-то принципу. Далее, мы можем параллельно запустить выборку на всех серверах и получить общий результат - ведь будет же работать - конечно, и быстрее, чем один SQL-сервер. А вот когда мы захотим сделать соединение таких таблиц, то тут наступит проблема - так как всех таблиц ни один SQL-сервер не знает - то есть - соединение будет невозможно - вот тут уже замечательные возможности SQL и кончаются.