При выполнении запроса, написанного на встроенном языке, в общем случае запрос парсится 3 раза:
Исходный запрос из конфигурации
Запрос SDBL
Запрос SQL (движком СУБД)
Парсинг запросов: Язык запросов - SDBL - SQL привносит дополнительные затраты, но они не значительны. С другой стороны, формулирование запросов в виде текста, а не в виде двоичных данных сложной структуры, значительно экономит время процессора и усилия разработчиков на их написание - или программное построение. Запросы бывают весьма сложные. Поэтому и было принято решение о текстовых запросах. Единственным исключением является участие в запросах длинных двоичных данных, для задания которых используется параметр в тексте запроса и отдельное двоичное значение с данными.
>"Ну у вас с платформой то разработчики работают, а не пользователи. Они если надо в for'е себе в ногу выстрелят (даже с большей легкостью)."
Тут не могу с вами согласиться исходя из личного опыта.
"DELETE FROM ..." написать гораздо проще и быстрее, особенно в консоли запросов (и случайно нажать шорткат для "выполнить" и потом кусать локти), чем в коде написать в for'е, а код потом надо ещё и запустить на исполнение - тут у программиста больше времени остается на "одуматься".
В известном смысле - да, ORM. Процитирую статью: "Учтя всё вышеперечисленное, мы поняли, что для решения наших задач надо писать свой собственный ORM, и даже нечто большее, чем просто ORM. Что мы, в итоге, и сделали."
По нашей информации - Firebird в бизнесе используется не так часто, как MS SQL или PostgreSQL например. А поддержка ещё одной СУБД - это серьезные расходы на разработку, тестирование и поддержку.
>"5. Появилась ли нормальная поддержка версионного режима, в смысле корректный прозрачный откат и перестарт транзакции, чтобы не заниматься ручными блокировками ?"
"Нормальная" - это от слова "норма". Можете пожалуйста пояснить (лучше на конкретном примере), что вы считаете нормой для поддержки версионного режима?
Технической или логической проблемы я тут не вижу.
Мы не реализуем механизм для группового изменения данных потому, что это "Веревка достаточной длины, чтобы… выстрелить себе в ногу". Коротко говоря - слишком мощный механизм при достаточно слабом его контроле. Можно будет, например, одной командой случайно удалить все заказы в системе. Что не очень хорошо.
>"всякие огромные документы инвентаризации "
Документ целиком как раз поменять/удалить можно. А вот набор документов одной командой - нет.
При выполнении запроса, написанного на встроенном языке, в общем случае запрос парсится 3 раза:
Исходный запрос из конфигурации
Запрос SDBL
Запрос SQL (движком СУБД)
Парсинг запросов: Язык запросов - SDBL - SQL привносит дополнительные затраты, но они не значительны. С другой стороны, формулирование запросов в виде текста, а не в виде двоичных данных сложной структуры, значительно экономит время процессора и усилия разработчиков на их написание - или программное построение. Запросы бывают весьма сложные. Поэтому и было принято решение о текстовых запросах. Единственным исключением является участие в запросах длинных двоичных данных, для задания которых используется параметр в тексте запроса и отдельное двоичное значение с данными.
>"приводит к запросам на запись в цикле. "
Согласен.
Пока это наша принципиальная позиция, почему - объяснил в комментарии выше про DML-запросы.
Такого у нас пока нет.
Не в последнюю очередь потому, что не у всех поддерживаемых нами СУБД есть такая фича.
>"Ну у вас с платформой то разработчики работают, а не пользователи. Они если надо в for'е себе в ногу выстрелят (даже с большей легкостью)."
Тут не могу с вами согласиться исходя из личного опыта.
"DELETE FROM ..." написать гораздо проще и быстрее, особенно в консоли запросов (и случайно нажать шорткат для "выполнить" и потом кусать локти), чем в коде написать в for'е, а код потом надо ещё и запустить на исполнение - тут у программиста больше времени остается на "одуматься".
В известном смысле - да, ORM.
Процитирую статью:
"Учтя всё вышеперечисленное, мы поняли, что для решения наших задач надо писать свой собственный ORM, и даже нечто большее, чем просто ORM. Что мы, в итоге, и сделали."
>"Зачем городить ещё одну дополнительную сущность в программах "
А что вы в данном случае называете дополнительной сущностью?
Попробуем со временем!
Тема, как вы понимаете, большая.
По нашей информации - Firebird в бизнесе используется не так часто, как MS SQL или PostgreSQL например. А поддержка ещё одной СУБД - это серьезные расходы на разработку, тестирование и поддержку.
То, что вы описали, напоминает мне функкциональность VIEW.
Это оно или я ошибаюсь?
И - такой функциональности у нас пока нет.
>"2. Встроили ли запросы в язык? Для resolve'инга, подсветки ошибок, синтаксиса и вот этого всего."
Можно сказать что да - в среде разработки 1C:Enterprise Development Tools для этого много сделано.
>"6. Возможность разработчику изменять самому физическую модель, материализовать показатели и т.п.?"
Боюсь что не понял вопроса.
"изменять самому физическую модель, материализовать показатели" - это как?
Можете пояснить на примерах пожалуйста?
>"5. Появилась ли нормальная поддержка версионного режима, в смысле корректный прозрачный откат и перестарт транзакции, чтобы не заниматься ручными блокировками ?"
"Нормальная" - это от слова "норма".
Можете пожалуйста пояснить (лучше на конкретном примере), что вы считаете нормой для поддержки версионного режима?
>"7. Поддержка наследования и полиморфизма в запросах?"
Если мы про язык запросов - в нем поддерживается ровно столько же наследования и полиморфизма, сколько поддерживается в языке SQL.
Возможно, я не понял ваш вопрос - можете пояснить на примерах?
Технической или логической проблемы я тут не вижу.
Мы не реализуем механизм для группового изменения данных потому, что это "Веревка достаточной длины, чтобы… выстрелить себе в ногу".
Коротко говоря - слишком мощный механизм при достаточно слабом его контроле. Можно будет, например, одной командой случайно удалить все заказы в системе. Что не очень хорошо.
>"всякие огромные документы инвентаризации "
Документ целиком как раз поменять/удалить можно.
А вот набор документов одной командой - нет.
>"4. Появились ли DML запросы? Или какой-то другой механизм для группового изменения данных?"
Не появились, и это на данный момент наша принципиальная позиция.
Много вопросов!
Отвечать буду по частям :)
>"почему не реализовали поддержку Firebird SQL? "
В смысле - как "рабочей" СУБД где хранятся бизнес-данные?
Наряду с MS SQL, PostgreSQL, Oracle и IBM DB2 ?
Всегда пожалуйста!
В конце статьи - ссылка на учебный план: https://spb.hse.ru/ma/systems/studyplan
и сайт программы: https://spb.hse.ru/ma/systems
Спасибо, будем смотреть.