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, меня про него ранее никогда не справшивали.
Более подробная информация тянет на отдельную статью, как-нибудь подготовим.
На данный момент это можно делать только в поле HTML-документа.
А что вас конкретно интересует?
Архитектурно там всё так же как и в клиент-серверном варианте, с т.з. настроек тоже.
Ссылку на выступления пока не нашли :(
А информацию можно найти тут:
https://illmatics.com/Understanding_the_LFH.pdf
http://illmatics.com/Windows 8 Heap Internals.pdf
ERP - более 12 млн строк.
Сейчас поищем ссылку на доклад. Найдем - разместим здесь.
Довольно давно это было.
Какие именно подробности вас интересуют?
Никак - но это то, что в ближайшее время может облегчить работу с большими БД.
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