PostgreSQL сейчас активно используется для приложений 1С, всё больше случаев миграции, по отзывам - существенных проблем с производительностью не встречено. Кстати, мы упростили процесс миграции инфобаз между СУБД.
Мы сами давно используем связку Linux+Postgre в нашем облачном сервисе 1cFresh.
Если будут DML операторы в запросах - всё вышеперечисленное работать не будет, чтобы работало - потребуются ОЧЕНЬ серьезные изменения в платформе. Навскидку - перенос большой части кода в триггеры на уровне СУБД, код триггеров тесно будет привязан к диалекту SQL конкретной СУБД, про кросс-платформенность придется позабыть и т.д. и т.п.
Принимая такое архитектурное решение, мы взвесили все "за" и "против", посмотрели на аналогичные продукты а рынке и на архитектурные решения, принятые в них.
Из своего личного опыта разработки (до-1Сного) скажу, что наличие прямых SQL-запросов в коде прикладного решения влечет за собой массу проблем (в частности, с производительностью) даже при переезде с одной версии СУБД на другую. И централизованно эти проблемы решить бывает очень накладно, т.к. их нужно решать в куче мест в прикладном коде. Приходится делать одно "бутылочное горлышко", через которое прикладной код обращается к СУБД, и пытаться оптимизировать запросы в этом "бутылочном горлышке". Ну а отсюда уже один шаг до SDBL.
Наличие прослойки в виде SDBL делает механизм менее гибким, согласен.
Но зато позволяет, в частности:
- Накладывать на запрос условия RLS (Row-Level Security) - Оптимизировать запросы на уровне платформы (один из примеров оптимизации описан в статье) - Адаптировать запрос для диалекта SQL конкретной СУБД (как опять же описано в статье)
Стандарт SQL - его даже флагманы индустрии СУБД поддерживают очень по разному - и в синтаксисе, и в реализации. Что-то сложнее "SELECT * FROM ..." уже начинает сильно разниться на MS SQL и Oracle например.
Ну видите - у каждого свой опыт и своя статистика использования БД. Я в частности работаю со сбором пожеланий по развитию платформы - пока не встречал запросов по поддержке Firebird (хотя сам лично с ней когда-то работал, когда она называлась Interbase). Кстати о пожеланиях по развитию платформы - мы их собираем в Телеграме, каждую пятницу собранные тут предложения приезжают ко мне и после уточнения деталей помещаются в нашу базу.
В ближайшее время - насколько знаю, таких планов нет. По моей личной статистике - бльше всего пока запросов на поддержку MySQL. Но моя личная статистика не влияет на планы развития платформы :) Вот тут ниже в каментах просят например Firebird, меня про него ранее никогда не справшивали.
При выполнении запроса, написанного на встроенном языке, в общем случае запрос парсится 3 раза:
Исходный запрос из конфигурации
Запрос SDBL
Запрос SQL (движком СУБД)
Парсинг запросов: Язык запросов - SDBL - SQL привносит дополнительные затраты, но они не значительны. С другой стороны, формулирование запросов в виде текста, а не в виде двоичных данных сложной структуры, значительно экономит время процессора и усилия разработчиков на их написание - или программное построение. Запросы бывают весьма сложные. Поэтому и было принято решение о текстовых запросах. Единственным исключением является участие в запросах длинных двоичных данных, для задания которых используется параметр в тексте запроса и отдельное двоичное значение с данными.
>"Ну у вас с платформой то разработчики работают, а не пользователи. Они если надо в for'е себе в ногу выстрелят (даже с большей легкостью)."
Тут не могу с вами согласиться исходя из личного опыта.
"DELETE FROM ..." написать гораздо проще и быстрее, особенно в консоли запросов (и случайно нажать шорткат для "выполнить" и потом кусать локти), чем в коде написать в for'е, а код потом надо ещё и запустить на исполнение - тут у программиста больше времени остается на "одуматься".
В известном смысле - да, ORM. Процитирую статью: "Учтя всё вышеперечисленное, мы поняли, что для решения наших задач надо писать свой собственный ORM, и даже нечто большее, чем просто ORM. Что мы, в итоге, и сделали."
Какие именно подробности вас интересуют?
Никак - но это то, что в ближайшее время может облегчить работу с большими БД.
1С будет запоминать настройки субд при реструкторизации.
Все новости по нашим планам мы публикуем здесь.
В 8.3.23 появилась сегментация данных.
Т.е. возможность размещать данные на разных дисках.
PostgreSQL сейчас активно используется для приложений 1С, всё больше случаев миграции, по отзывам - существенных проблем с производительностью не встречено. Кстати, мы упростили процесс миграции инфобаз между СУБД.
Мы сами давно используем связку Linux+Postgre в нашем облачном сервисе 1cFresh.
Да, забыл самое важное! Настолько давно и глубоко встроенное в платформу, что про это со временем даже забываешь.
Существенная часть механизмов платформы завязано на объектную технику и контроль над изменениями:
обработчики
обмен данными (регистрация изменений) - для построения распределенных баз
история данных
журналирование
хранимые итоги
управляемые блокировки
... и другое
Если будут DML операторы в запросах - всё вышеперечисленное работать не будет, чтобы работало - потребуются ОЧЕНЬ серьезные изменения в платформе. Навскидку - перенос большой части кода в триггеры на уровне СУБД, код триггеров тесно будет привязан к диалекту SQL конкретной СУБД, про кросс-платформенность придется позабыть и т.д. и т.п.
Понимаю вас.
Принимая такое архитектурное решение, мы взвесили все "за" и "против", посмотрели на аналогичные продукты а рынке и на архитектурные решения, принятые в них.
Из своего личного опыта разработки (до-1Сного) скажу, что наличие прямых SQL-запросов в коде прикладного решения влечет за собой массу проблем (в частности, с производительностью) даже при переезде с одной версии СУБД на другую. И централизованно эти проблемы решить бывает очень накладно, т.к. их нужно решать в куче мест в прикладном коде. Приходится делать одно "бутылочное горлышко", через которое прикладной код обращается к СУБД, и пытаться оптимизировать запросы в этом "бутылочном горлышке". Ну а отсюда уже один шаг до SDBL.
Недостатки - это продолжение достоинств (с).
Наличие прослойки в виде SDBL делает механизм менее гибким, согласен.
Но зато позволяет, в частности:
- Накладывать на запрос условия RLS (Row-Level Security)
- Оптимизировать запросы на уровне платформы (один из примеров оптимизации описан в статье)
- Адаптировать запрос для диалекта SQL конкретной СУБД (как опять же описано в статье)
Стандарт SQL - его даже флагманы индустрии СУБД поддерживают очень по разному - и в синтаксисе, и в реализации. Что-то сложнее "SELECT * FROM ..." уже начинает сильно разниться на MS SQL и Oracle например.
Записал.
Ну видите - у каждого свой опыт и своя статистика использования БД.
Я в частности работаю со сбором пожеланий по развитию платформы - пока не встречал запросов по поддержке Firebird (хотя сам лично с ней когда-то работал, когда она называлась Interbase).
Кстати о пожеланиях по развитию платформы - мы их собираем в Телеграме, каждую пятницу собранные тут предложения приезжают ко мне и после уточнения деталей помещаются в нашу базу.
Если я вас правильно понял - вы предлагаете писать SQL-запросы непосредственно в коде 1С?
Поправьте меня если ошибаюсь.
Пример получения нового кода сознаетльно описан нами упрощенно.
Функциональность автонумерации описана здесь (но нужен доступ на ИТС).
>"3. Поддержка оконных функций и рекурсивных CTE в запросах для работы с порядками и рекурсиями "
Такого пока нет, но запросы на эту функциональность есть.
Возьмемся реализовывать - напишем на Зазеркалье с указанием планируемой версии платформы.
>"1. Появился ли в оптимизаторе Predicate Push Down?"
Такого пока нет.
В ближайшее время - насколько знаю, таких планов нет.
По моей личной статистике - бльше всего пока запросов на поддержку MySQL.
Но моя личная статистика не влияет на планы развития платформы :)
Вот тут ниже в каментах просят например Firebird, меня про него ранее никогда не справшивали.
Как говорится - следите за новостями!
Публичные планы мы размещаем на Зазеркалье.
Вот например предварительный план на версию 8.3.26
При выполнении запроса, написанного на встроенном языке, в общем случае запрос парсится 3 раза:
Исходный запрос из конфигурации
Запрос SDBL
Запрос SQL (движком СУБД)
Парсинг запросов: Язык запросов - SDBL - SQL привносит дополнительные затраты, но они не значительны. С другой стороны, формулирование запросов в виде текста, а не в виде двоичных данных сложной структуры, значительно экономит время процессора и усилия разработчиков на их написание - или программное построение. Запросы бывают весьма сложные. Поэтому и было принято решение о текстовых запросах. Единственным исключением является участие в запросах длинных двоичных данных, для задания которых используется параметр в тексте запроса и отдельное двоичное значение с данными.
>"приводит к запросам на запись в цикле. "
Согласен.
Пока это наша принципиальная позиция, почему - объяснил в комментарии выше про DML-запросы.
Такого у нас пока нет.
Не в последнюю очередь потому, что не у всех поддерживаемых нами СУБД есть такая фича.
>"Ну у вас с платформой то разработчики работают, а не пользователи. Они если надо в for'е себе в ногу выстрелят (даже с большей легкостью)."
Тут не могу с вами согласиться исходя из личного опыта.
"DELETE FROM ..." написать гораздо проще и быстрее, особенно в консоли запросов (и случайно нажать шорткат для "выполнить" и потом кусать локти), чем в коде написать в for'е, а код потом надо ещё и запустить на исполнение - тут у программиста больше времени остается на "одуматься".
В известном смысле - да, ORM.
Процитирую статью:
"Учтя всё вышеперечисленное, мы поняли, что для решения наших задач надо писать свой собственный ORM, и даже нечто большее, чем просто ORM. Что мы, в итоге, и сделали."
>"Зачем городить ещё одну дополнительную сущность в программах "
А что вы в данном случае называете дополнительной сущностью?