1. Я написал вам, что мешает сделать возможность использовать функциональность конкретной СУБД при внедрении, хотя бы те возможности, которые не противоречат встроенному языку (например кореллированные подзапросы). До версии платформы 8.2 можно было использовать несколько полей в условии В соединения. В 8.2 это обрубили. По поводу ROW_NUMBER тоже хотелось бы комментарий увидеть.
2. Такие библиотеки как node.js никогда бы не появились, если бы не появились среды исполнения javascript с бинарной трансляцией. В свое время в УПП появилась «оптимизация» корректировки стоимости на временных таблицах. РАУЗ в УПП и партии в ERP уже полностью на временных таблицах. Если бы не было проблем с производительностью встроенного языка — такое извращение никогда не появилось бы.
4. Логика СУБД это не только хранимые процедура, а выполнение разных расчетов на сервере. Из-за низкой производительности встроенного языка многие вычисления действительно выгоднее загнать во временные таблицы на сервер баз данных и затем вернуть результат.
5. Я неправильно написал вопрос, вы как бывший сотрудник MBS должны помнить, чем отличается интернационализация в Navision от Axapta. Вот хочется как в Axapta,
Вообще зря я все это написал, это официальны блок и вряд ли вы ответите что-то отличное от того, что отвечаете на партнерке
Хотелось бы получить ответ на следующие вопросы.
1. С чем связан отказ от тонкой кастомизации работы с БД. Ваша цель понятна — одинаковая работа приложения на всех 4-х СУБД, включая файловую версию. Но моя многолетняя практика работы на крупных проектах показывает, что смена БД в течение эксплуатации не происходит никогда. Разумеется, что MS SQL Server развивается гораздо быстрее файловой ИБ, но ведь клиент покупает вместе с 1С лицензии на MS SQL Server вместе со всеми своими функциями, но пользоваться ими не может. Вот некоторое из того, чего реально не хватает:
1.1. Добавление нескольких индексов по произвольным полям
1.2. Получение номера строки выборки ROW_NUMBER в MS SQL Server
1.3. Коррелированные подзапросы
Все это могло бы решаться некоторыми профилями тонкой настройки, которые выполняются вендором у конкретного клиента
2. Добавление бинарной трансляции p-кода. Вас не расстаивает, что Java-Script на веб-клиенте выполняется в тысячи раз быстрее встроенного языка?
3. Вместо того, чтобы добавить классы (интерфейсы) определяемые пользователем сделали выделение интерфейсов с помощью областей кода. При этом некоторые обработки и общие модули используются как реализации некоторых интерфейсов.
4. Судя по ERP 2 произошел крутой поворот в сторону выполнения всей логики на СУБД. На мой взгляд это шаг назад, так как алгоритмические языки всегда более понятные и удобные для поддержки/доработки чем скрипты на SQL. Так и до PL/SQL можно дойти
5. Когда наконец произойдет отказ от хранения текстов требующих перевода в отдельной части дерева конфигурации, чтобы во-первых дисциплинировать программистов не писать кучу разных вариантов вывода одного сообщения и возможности делать перевод не усложняя обновление.
1. Я не участвую в разработке платформы, сами разработчики тоже об этом не распространяются, поэтому могу лишь предположить, что причина в унифицированном доступе к остаткам. То есть заблокировали записи с остатками, проверили их, изменили. С версионными СУБД все по-другому, сначала их нужно изменить, а затем проверить. Если при списании остатка нужно использовать FIFO все еще сложнее. Кроме того собственный механизм блокировок оказался очень полезен даже для MS SQL Server, т.к. он очень любит эскалировать блокировки до таблицы даже для небольшого набора записей.
2. Я не могу сказать, какие запросы использует платформа, чтобы заблокировать всю таблицу в Postgre SQL. Главное что платформа это делает.
Механизм ORM использующийся в платформе был изначально написан для блокировочных СУБД. Чтобы добавит поддержку версионных БД был разработан собственный механизм блокировок, который используется сейчас по умолчанию для всех новых конфигураций.
Такие запросы генерируются, когда отключен собственный механизм блокировок, чтобы делать блокировку на уровне таблицы. Этот режим сделан как заглушка, чтобы обеспечить правильность работы приложения для старых конфигураций.
2. Такие библиотеки как node.js никогда бы не появились, если бы не появились среды исполнения javascript с бинарной трансляцией. В свое время в УПП появилась «оптимизация» корректировки стоимости на временных таблицах. РАУЗ в УПП и партии в ERP уже полностью на временных таблицах. Если бы не было проблем с производительностью встроенного языка — такое извращение никогда не появилось бы.
4. Логика СУБД это не только хранимые процедура, а выполнение разных расчетов на сервере. Из-за низкой производительности встроенного языка многие вычисления действительно выгоднее загнать во временные таблицы на сервер баз данных и затем вернуть результат.
5. Я неправильно написал вопрос, вы как бывший сотрудник MBS должны помнить, чем отличается интернационализация в Navision от Axapta. Вот хочется как в Axapta,
Вообще зря я все это написал, это официальны блок и вряд ли вы ответите что-то отличное от того, что отвечаете на партнерке
1. С чем связан отказ от тонкой кастомизации работы с БД. Ваша цель понятна — одинаковая работа приложения на всех 4-х СУБД, включая файловую версию. Но моя многолетняя практика работы на крупных проектах показывает, что смена БД в течение эксплуатации не происходит никогда. Разумеется, что MS SQL Server развивается гораздо быстрее файловой ИБ, но ведь клиент покупает вместе с 1С лицензии на MS SQL Server вместе со всеми своими функциями, но пользоваться ими не может. Вот некоторое из того, чего реально не хватает:
1.1. Добавление нескольких индексов по произвольным полям
1.2. Получение номера строки выборки ROW_NUMBER в MS SQL Server
1.3. Коррелированные подзапросы
Все это могло бы решаться некоторыми профилями тонкой настройки, которые выполняются вендором у конкретного клиента
2. Добавление бинарной трансляции p-кода. Вас не расстаивает, что Java-Script на веб-клиенте выполняется в тысячи раз быстрее встроенного языка?
3. Вместо того, чтобы добавить классы (интерфейсы) определяемые пользователем сделали выделение интерфейсов с помощью областей кода. При этом некоторые обработки и общие модули используются как реализации некоторых интерфейсов.
4. Судя по ERP 2 произошел крутой поворот в сторону выполнения всей логики на СУБД. На мой взгляд это шаг назад, так как алгоритмические языки всегда более понятные и удобные для поддержки/доработки чем скрипты на SQL. Так и до PL/SQL можно дойти
5. Когда наконец произойдет отказ от хранения текстов требующих перевода в отдельной части дерева конфигурации, чтобы во-первых дисциплинировать программистов не писать кучу разных вариантов вывода одного сообщения и возможности делать перевод не усложняя обновление.
2. Я не могу сказать, какие запросы использует платформа, чтобы заблокировать всю таблицу в Postgre SQL. Главное что платформа это делает.
Такие запросы генерируются, когда отключен собственный механизм блокировок, чтобы делать блокировку на уровне таблицы. Этот режим сделан как заглушка, чтобы обеспечить правильность работы приложения для старых конфигураций.