В статье есть неточность — нет никакого байт-кода в 1С. Байт-код должен быть на языке низкого уровня, а в 1С это просто закодированные инструкции встроенного языка.
Также интересно, почему отказались от поддержки на тонком клиенте таблицы значений и дерева значений? Выход конечно есть — массив со структурами, но все-таки почему?
Автор явно не учитывает тот факт, что технологические новинки всегда стоят дорого, именно из-за необходимости окупить разработку и оплатить патенты. Сегодня за 10K можно купить телефон, который по возможностям/качеству будет соответствовать топу 5-ти летней давности. Так это каждый для себя выбирает, нужны ли ему новые возможности.
1. Я имел ввиду перенос блока с уровня на уровень, например необходимо добавить новый блок на уровень, а их там уже 5 и нужно вставить еще один уровень, на котором будет 3 элемента, а существующие необходимо между ними распределить. Не нашел в СППР функционала, который позволяет это сделать без повторного ввода.
5. Никто не мешает делать в конфигурации дублирующиеся учетные механизмы, под старую и под новую версию отчетности, но то что отчетность занимает почти треть от всей конфигурации — это слишком.
6. То есть исполнитель ставит оценку, а руководитель разработки ее подтверждает? Есть ли санкции для разработчика, который постоянно не укладывается в оценку? Или его просто переводят на обновление регламентированной отчетности?
1. Перед параметрами необходимо писать описания. Рядом стоящие параметры разрывать нельзя. У меня было несколько проектов по переводу и никогда переводчик не жаловался на недостаток информации в сообщениях. Главное, чтобы переводчик должен знать предметную область. На одном проекте кстати один разработчик стал делать как вы в ERP, переводчик это дело сразу зарезал, т.к. системы технического перевода типа SDL Trados Studio очень плохо работают с двуязычными строками
2. Технические ошибки всегда были, а ошибки перевода вообще никак на функциональность не влияют
3. Про перевод текста конфигурации вопрос гораздо более сложный и думаю вы с ним столкнетесь, когда захотите продавать ERP за пределами русскоязычной зоны.
Не нужно передергивать мои слова, я писал «по всей видимости новички», а не неумехи. Вопрос этот очень важный при переводе, просто они об этом не задумываются, значит не такие опытные как команда разработки БСП.
А какой я еще должен сделать вывод? Если данный формат строк для перевода используется во всей конфигурации, значит это прописано в регламенте разработки. Почему за все это время никто не обратил на это внимание?
Потому, что БСП пишет опытная команда разработчиков, которая понимает для чего функция НСтр и поэтому использует индексы параметра в строках НСтр, а разработчики ERP по всей видимости новички.
Пример разработки ERP:
ШаблонСообщения = НСтр(«ru = 'Номенклатура %НоменклатураХарактеристика% %Назначение%
|Превышен оперативный складской остаток на складе „“%Склад%»" на %Количество% %Единица%'");
Если строку внутри НСтр передать переводчику для перевода на английский язык, что он напишет? И так во всей конфигурации!
Функциональная модель проекта в нотации IDEF0 разрабатывается и хранится в СППР.
1. Кем она разрабатывается? Неужели вы ее разрабатываете в редакторе графических схем внутри СППР? Это ведь абсалютно неудобное средство, например по сравнению с BPWin. Как вы переносите элементы с уровня на уровень?
2. Вы написали, что в СППР вносятся изменения на этапе 3, при этом на этапе 5 проект может быть не готов в включению в очередной релиз. То есть изменения вносятся в какую-то ветку СППР, а затем каким то образом переносятся в основную ветку?
3. Кто пишет справку, сами разработчики или отдельные технические писатели. Как синхронизирована встроенная справка и документация?
4. Как разработчики ERP смирились с тем, что запись конфигурации после небольшого изменения занимает от 40 секунд (при работе на сервере приложений) до 3 минут при файловой базе?
5. Почему в состав конфигурации входит регламентированная отчетность, которая занимает огромную часть из указанного вами объема строк кода и которая может поставляться отдельной поставкой и также отдельно обновляться?
6. В СППР есть поле оценка. Кто ее выполняет и контролирует. Есть ли анализ, почему оценка была превышена, есть ли какие-то штрафы для разработчика, регулярно превышающего оценку?
7. По вашей оценке, если необходимо добавить в конфигурацию в какой либо справочник новый реквизит и вывести его на форму сколько человеко-часов это потребует (хотя бы приблизительно общее количество времени на обсуждение, прототип, разработка, тестирование, справка, внесение в СППР и т.п.)
Напишите про организацию рабочего процесса при разработке конфигураций, например ERP 2. И как получается, что например в одном релизе происходит массовая замена (тысячи вызовов) СтроковыеФункцииКлиентСервер.ПодставитьПараметрыВСтроку() на СтрШаблон(), а через месяц обратно.
Дайте пожалуйста ссылку или цитату. Не припоминаю, что я писал подобное.
Согласен, коррелирующие подзапросы непосредственно в тексте запроса были бы удобны. Сейчас такие задачи приходится решать через временные таблицы. Но тут мы приходим к стандартной задаче в жизненном цикле большого софтверного продукта. Есть запрос на новую функциональность (коррелирующие подзапросы). При этом задача, для решения которой требуется эта новая функциональность, уже решается существующей функциональностью (временными таблицами), пусть и не так изящно. А еще у нас есть список других запросов на новую функциональность, в том числе и ту, которая решает задачи, до сих пор решения в рамках системы решения не имеющие.
Как мне кажется, вы еще не знаете, о чем идет речь, но уже выносите суждение.
Можете поверить на слово. После выходя очередной версии платформы я внимательно читаю весь список изменений и сразу определяю для себя возможности их использования на реальных проектах
Подобные высказывания от вас как раз подтверждают то, о чем я написал в habrahabr.ru/company/1c/blog/269611/#comment_8644699. У вашего руководителя есть новые бизнес-идеи (работа в облаке, интерфейс Такси и т.п.). Именно их запросы вы и реализуете. То как это будет использоваться в типовых решениях или у клиентов вам мало интересно. Посмотрите сколько вопросов по платформе накопилось за последние 2 года на партнерском форуме без внятного ответа. Раньше такого безобразия не было. И партнерский семинар и ваш выход на площадку habrahabr это чистый пиар, без желания получить обратную связь
Где я такое писал? Дайте пожалуйста ссылку или цитату.
Вы ставите приоритет на функциональность платформы, а не на способы реализации типового решения
Про это рассказывали на октябрьском семинаре.
повторюсь, это все маркетинговые возможности к реальным внедрениям не имеющие никакого отношения
Ваш запрос можно модифицировать так, чтобы он заработал на 8.2:
Этот запрос да, но он был представлен для примера в общем случае у нас есть несколько полей в присоединяемой таблице по которым необходимо выполнить соединение и которые так просто переписать нельзя. приходится вычислять номер строки (который вы не в состоянии добавить) и использовать его в качестве идентификатора строки
Давайте посмотрим шире — в мире вообще мало случаев, когда на аналогичных платформах партнерами
Разумеется, поэтому я и написал, что разработчикам платформы нельзя отмежеваться от разработчиков флагманской типовой конфигурации, что вы пытались сделать несколько постов назад
Почему так считаете? Мы переносим в расширения все больше и больше объектов
Да потому что на проектах внедрения никогда не было проблем с новыми объектами или реквизитами. Как например ваши расширения помогут, если для реализации требований клиента необходимо внести изменения в типовой функционал (модули), который потом будет обновляться?
введение такой «полуподдерживаемой» функциональности в платформу через пару версий их активного использования прикладными разработчиками приводит к проблемам в поддержке и развитии платформы
Повторюсь, на проектах внедрения (не только 1С) всегда есть этап Performance Tuning, то есть тонкая настройка системы для конкретного клиента. Ваша платформа таких возможностей не предоставляет, что по мнению многих разработчиков 1С — плохо. Кроме того, требования конечного пользователя гораздо более детальные чем маркетинговые требования массового продукта, что может потребовать нестандартных решений. Ваша платформа таких возможностей не предоставляет.
Можете написать такой запрос для демо-базы, который работает на 8.1 и не работает на 8.3?
ВЫБРАТЬ
Товары.Ссылка,
ЦеныТоваров.Цена
ИЗ Справочник.Номенклатура КАК Товары
ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ЦеныНоменклатуры КАК ЦеныТоваров
ПО
(ЦеныТоваров.Номенклатура, ЦеныТоваров.ТипЦен) В (
ВЫБРАТЬ ПЕРВЫЕ 1
Подчиненные.Номенклатура,
Подчиненные.ТипЦен
ИЗ РегистрСведений.ЦеныНоменклатуры КАК Подчиненные
ГДЕ
Подчиненные.Номенклатура = Товары.Ссылка
УПОРЯДОЧИТЬ ПО
Период
)
Проверять нужно на клиент-серверной базе SQL Server УПП 1.2-1.3. На файловой базе 8.1 валится с ошибкой, на платформе 8.3 в режиме совместимости 8.1 выдает ошибку, как без режима совместимости
О каком вопросе речь, напомните пожалуйста. Возможно я не в курсе.
Ну и надо помнить что год — не то чтобы очень большой срок для софтверного проекта в миллионы строк кода.
Сделайте поиск — «опрос по средствам разработки». Оказывается опрос был в начале 2013 года, то есть почти три года прошло.
А платформу как таковую для создания тиражных конфигураций для различных областей бизнеса используют партнеры; то, что 1С-совместимых конфигураций создано более тысячи, говорит, на мой взгляд, о соответствии платформы решаемым ей задачам.
…
Не всегда это так; например, в компании Вкусвилл система управления написана на 1С с нуля.
Назовите разработанную с 0 конфигурацию по сложности и функциональности сопоставимую с ERP 2 или хотя бы УПП.
Мы это делаем — вот, вот, и вот, и еще много другого
Уж расширения точно сделаны не для внедренцев. Это механизм, необходимый для полноценной работы другой вашей мечты — работе в облаке. Для проектов внедрения — никак не пригодится. А уж про выгрузку конфигурации в файлы не стоило упоминать. Вас давно просили сделать, чтобы при выгрузке отслеживались версии файлов, что на порядки могло бы ускорить выгрузку/загрузку. В 1cpp для платформы 7.7 это работало и прекрасно использовали платформу с хранилищами на SVN. Сейчас одна надежда на ET.
Делать так — значит ступать на очень скользкую дорогу, что весьма рискованно как для нас, так и для партнеров и внедренцев.
Один из вариантов — не давать сертификат 1С: Совместимо для конфигураций, которые используют такие конструкции. Это хоть какой то выход.
Я могу вам сказать, что система оперативного учета на платформе 7.7 SQL с использованием 1cpp и ToyBlocking даст огромную форму платформе 8.3 в части производительности, учитывая например возможности использования индексированных представлений.
Вы уверены, что это не работает в 8.3?
Я только что попробовал — вот такой запрос (с условием соединения идентичным, если не ошибаюсь, вашему) работает на демо-базе.
Попробуйте использовать в () поля из присоединяемой таблицы, а в подзапросе тоже выбирать данные из присоединяемой таблицы, а не из основной и все встанет на свои места
ROW_NUMBER() не работает в SQL2000, а мы его до сих пор поддерживаем.
Я повторюсь, вы могли бы сделать для SQL2000 реализацию на основе полного соединения, может и стимул появился бы у пользователей для перехода на более новые версии. Ведь прошло 15 лет. У нас многие клиенты с 7.7 работают на SQL 2008 (правда не совсем документированным способом)
У вас есть доступ в партнерский форум? Открывайте топики, устраивайте дискуссии, мы только «за».
Таких топиков полно, только без участия разработчиков платформы и конфигураций. Смысл?
В прошлом году подняли вопрос о том, чего не хватает в платформе. Не хотите обсудить, что из этого сделали? А судя по извращениям разработчиков типовых — лестница между этажами закрыта и лифты не ходЮт.
Вот мы и подошли с вами к глубинным проблемам, которые вызывают недовольство в сообществе разработчиков на 1С.
1. Отсутствие тесного контакта между разработчиками платформы и конфигураций.
Давайте скажу прямо. Ваша платформа, не смотря на ее технологичность без типовых конфигураций никому не нужна. Если в компании нет 1С, без качественной конфигурации, покрывающей хотя бы половину потребностей — она там не появится. Поэтому проблемы с производительностью флагманского решения и применяемые там способы разработки — это в том числе ВАШИ проблемы. Пока вы развиваете тупиковые темы типа интерфейса Такси, разработчики конфигураций занимаются извращениями.
2. Отсутствие заботы разработчиков платформы и разработчиков конфигурации о тех, кто занимается внедрением и просто доработкой типовых конфигураций. Вы делаете некоторое общее решение, которое покрывает какой-то процент потребностей конечного пользователя. Одна из ваших задач — предоставление средств для упрощения доработок. Те же коррелированные подзапросы нужны не просто так, а для того чтобы в существующий запрос вставить получение дополнительного поля без усложнения дальнейшего обновления. Есть СУБД которые поддерживают их нативно и вместо того, чтобы сделать либо реализацию (пусть медленную) для остальных СУБД или просто разрешить использовать ее только при доработках, вы обрубаете это возможность вообще.
Теперь ответы на вопросы:
1.1. до 8.2 была возможна следующая конструкция
СОЕДИНЕНИЕ Таблица1 КАК Строки1
ПО (Поле1, Поле2) В (
ВЫБРАТЬ ПЕРВЫЕ 1
Поле1, Поле2
ИЗ Таблица1 КАК Строки2
УПОРЯДОЧИТЬ ПО
Поле1, Поле2)
это не работало на всех СУБД кроме SQL Server. В 8.2 (видимо решили, что это унизит Oracle) эту возможность обрубили и оставили возможность использовать только одно поле.
1.2. Получение номера строки выборки:
SQL Server, ROW_NUMBER, 2005
Oracle Database, row_number() over()
IBM DB2, row_number() over()
Postgre, row_number() over()
Похоже что только на файловой нет
Еще более веселая штука, связанная с регистрами сведений. В базу добавляется поле _SimpleKey, которое является идентификатором записи регистра сведений и которое используется в механизмах платформы. Но во встроенном языке к нему доступа нет. А теперь представьте себе размер извращения, чтобы для каждой строки запроса получить последнее значение ресурса регистра сведений, имеющего несколько измерений.
2. Если вы будете продолжать делать упор на то, что производительность встроенного языка не важна — так и пишите в книге по встроенному языку — «это не язык, а скрип и необходимо минимизировать его использование. А если нужно что-то посчитать — внешние компоненты вам в помощь».
4. Именно, дошло до того, что многие разработчики, даже опытные, насмотревшись примером из ERP 2 начинают использовать временные таблицы вообще везде. Вообще это пошло еще с ЗУП 2, когда запросы на несколько тысяч строк стали нормой, опять же из-за низкой производительности встроенного языка, которая на задачах расчета зарплаты отразилась наиболее остро
Вообще на партнерке вам пишут очень много дельных предложений и замечаний, но на большинство из них идут либо «пожелание записано», либо «мы считаем что этого не нужно». По поводу «скорости» реализации пожеланий приведу 2 примера:
В 2005 году впервые подняли вопрос о необходимости использования merge при сравнении/объединении конфигураций. Данная функция появилась в 2014 (9 лет).
В тестовой версии 8.3.7 (2015 год) появилось динамическое обновление клиент/серверной базы без перезапуска конфигуратора — у нас люди плакали от счастья, хотя проблему стали обсуждать сразу после выхода платформы (2004 год)
По таким вопросам как ООП, производительность встроенного языка, развитие языка запросов должны быть постоянно открытые топики на партнерке с обсуждением всех заинтересованных сторон. Сейчас разработчики типовых конфигураций вообще не участвуют в топиках по платформе (видимо это у вас запрещено правилами внутреннего распорядка).
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. Главное что платформа это делает.
Также интересно, почему отказались от поддержки на тонком клиенте таблицы значений и дерева значений? Выход конечно есть — массив со структурами, но все-таки почему?
5. Никто не мешает делать в конфигурации дублирующиеся учетные механизмы, под старую и под новую версию отчетности, но то что отчетность занимает почти треть от всей конфигурации — это слишком.
6. То есть исполнитель ставит оценку, а руководитель разработки ее подтверждает? Есть ли санкции для разработчика, который постоянно не укладывается в оценку? Или его просто переводят на обновление регламентированной отчетности?
2. Технические ошибки всегда были, а ошибки перевода вообще никак на функциональность не влияют
3. Про перевод текста конфигурации вопрос гораздо более сложный и думаю вы с ним столкнетесь, когда захотите продавать ERP за пределами русскоязычной зоны.
ШаблонСообщения = НСтр(«ru = 'Номенклатура %НоменклатураХарактеристика% %Назначение%
|Превышен оперативный складской остаток на складе „“%Склад%»" на %Количество% %Единица%'");
Если строку внутри НСтр передать переводчику для перевода на английский язык, что он напишет? И так во всей конфигурации!
1. Кем она разрабатывается? Неужели вы ее разрабатываете в редакторе графических схем внутри СППР? Это ведь абсалютно неудобное средство, например по сравнению с BPWin. Как вы переносите элементы с уровня на уровень?
2. Вы написали, что в СППР вносятся изменения на этапе 3, при этом на этапе 5 проект может быть не готов в включению в очередной релиз. То есть изменения вносятся в какую-то ветку СППР, а затем каким то образом переносятся в основную ветку?
3. Кто пишет справку, сами разработчики или отдельные технические писатели. Как синхронизирована встроенная справка и документация?
4. Как разработчики ERP смирились с тем, что запись конфигурации после небольшого изменения занимает от 40 секунд (при работе на сервере приложений) до 3 минут при файловой базе?
5. Почему в состав конфигурации входит регламентированная отчетность, которая занимает огромную часть из указанного вами объема строк кода и которая может поставляться отдельной поставкой и также отдельно обновляться?
6. В СППР есть поле оценка. Кто ее выполняет и контролирует. Есть ли анализ, почему оценка была превышена, есть ли какие-то штрафы для разработчика, регулярно превышающего оценку?
7. По вашей оценке, если необходимо добавить в конфигурацию в какой либо справочник новый реквизит и вывести его на форму сколько человеко-часов это потребует (хотя бы приблизительно общее количество времени на обсуждение, прототип, разработка, тестирование, справка, внесение в СППР и т.п.)
www.microsoft.com/ru-ru/server-cloud/products/sql-server-2005
Согласен, коррелирующие подзапросы непосредственно в тексте запроса были бы удобны. Сейчас такие задачи приходится решать через временные таблицы. Но тут мы приходим к стандартной задаче в жизненном цикле большого софтверного продукта. Есть запрос на новую функциональность (коррелирующие подзапросы). При этом задача, для решения которой требуется эта новая функциональность, уже решается существующей функциональностью (временными таблицами), пусть и не так изящно. А еще у нас есть список других запросов на новую функциональность, в том числе и ту, которая решает задачи, до сих пор решения в рамках системы решения не имеющие.
Можете поверить на слово. После выходя очередной версии платформы я внимательно читаю весь список изменений и сразу определяю для себя возможности их использования на реальных проектах
Подобные высказывания от вас как раз подтверждают то, о чем я написал в habrahabr.ru/company/1c/blog/269611/#comment_8644699. У вашего руководителя есть новые бизнес-идеи (работа в облаке, интерфейс Такси и т.п.). Именно их запросы вы и реализуете. То как это будет использоваться в типовых решениях или у клиентов вам мало интересно. Посмотрите сколько вопросов по платформе накопилось за последние 2 года на партнерском форуме без внятного ответа. Раньше такого безобразия не было. И партнерский семинар и ваш выход на площадку habrahabr это чистый пиар, без желания получить обратную связь
Вы ставите приоритет на функциональность платформы, а не на способы реализации типового решения
повторюсь, это все маркетинговые возможности к реальным внедрениям не имеющие никакого отношения
Этот запрос да, но он был представлен для примера в общем случае у нас есть несколько полей в присоединяемой таблице по которым необходимо выполнить соединение и которые так просто переписать нельзя. приходится вычислять номер строки (который вы не в состоянии добавить) и использовать его в качестве идентификатора строки
Разумеется, поэтому я и написал, что разработчикам платформы нельзя отмежеваться от разработчиков флагманской типовой конфигурации, что вы пытались сделать несколько постов назад
Да потому что на проектах внедрения никогда не было проблем с новыми объектами или реквизитами. Как например ваши расширения помогут, если для реализации требований клиента необходимо внести изменения в типовой функционал (модули), который потом будет обновляться?
Повторюсь, на проектах внедрения (не только 1С) всегда есть этап Performance Tuning, то есть тонкая настройка системы для конкретного клиента. Ваша платформа таких возможностей не предоставляет, что по мнению многих разработчиков 1С — плохо. Кроме того, требования конечного пользователя гораздо более детальные чем маркетинговые требования массового продукта, что может потребовать нестандартных решений. Ваша платформа таких возможностей не предоставляет.
ВЫБРАТЬ
Товары.Ссылка,
ЦеныТоваров.Цена
ИЗ Справочник.Номенклатура КАК Товары
ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ЦеныНоменклатуры КАК ЦеныТоваров
ПО
(ЦеныТоваров.Номенклатура, ЦеныТоваров.ТипЦен) В (
ВЫБРАТЬ ПЕРВЫЕ 1
Подчиненные.Номенклатура,
Подчиненные.ТипЦен
ИЗ РегистрСведений.ЦеныНоменклатуры КАК Подчиненные
ГДЕ
Подчиненные.Номенклатура = Товары.Ссылка
УПОРЯДОЧИТЬ ПО
Период
)
Проверять нужно на клиент-серверной базе SQL Server УПП 1.2-1.3. На файловой базе 8.1 валится с ошибкой, на платформе 8.3 в режиме совместимости 8.1 выдает ошибку, как без режима совместимости
Сделайте поиск — «опрос по средствам разработки». Оказывается опрос был в начале 2013 года, то есть почти три года прошло.
Назовите разработанную с 0 конфигурацию по сложности и функциональности сопоставимую с ERP 2 или хотя бы УПП.
Уж расширения точно сделаны не для внедренцев. Это механизм, необходимый для полноценной работы другой вашей мечты — работе в облаке. Для проектов внедрения — никак не пригодится. А уж про выгрузку конфигурации в файлы не стоило упоминать. Вас давно просили сделать, чтобы при выгрузке отслеживались версии файлов, что на порядки могло бы ускорить выгрузку/загрузку. В 1cpp для платформы 7.7 это работало и прекрасно использовали платформу с хранилищами на SVN. Сейчас одна надежда на ET.
Один из вариантов — не давать сертификат 1С: Совместимо для конфигураций, которые используют такие конструкции. Это хоть какой то выход.
Я могу вам сказать, что система оперативного учета на платформе 7.7 SQL с использованием 1cpp и ToyBlocking даст огромную форму платформе 8.3 в части производительности, учитывая например возможности использования индексированных представлений.
Попробуйте использовать в () поля из присоединяемой таблицы, а в подзапросе тоже выбирать данные из присоединяемой таблицы, а не из основной и все встанет на свои места
Я повторюсь, вы могли бы сделать для SQL2000 реализацию на основе полного соединения, может и стимул появился бы у пользователей для перехода на более новые версии. Ведь прошло 15 лет. У нас многие клиенты с 7.7 работают на SQL 2008 (правда не совсем документированным способом)
Таких топиков полно, только без участия разработчиков платформы и конфигураций. Смысл?
В прошлом году подняли вопрос о том, чего не хватает в платформе. Не хотите обсудить, что из этого сделали? А судя по извращениям разработчиков типовых — лестница между этажами закрыта и лифты не ходЮт.
1. Отсутствие тесного контакта между разработчиками платформы и конфигураций.
Давайте скажу прямо. Ваша платформа, не смотря на ее технологичность без типовых конфигураций никому не нужна. Если в компании нет 1С, без качественной конфигурации, покрывающей хотя бы половину потребностей — она там не появится. Поэтому проблемы с производительностью флагманского решения и применяемые там способы разработки — это в том числе ВАШИ проблемы. Пока вы развиваете тупиковые темы типа интерфейса Такси, разработчики конфигураций занимаются извращениями.
2. Отсутствие заботы разработчиков платформы и разработчиков конфигурации о тех, кто занимается внедрением и просто доработкой типовых конфигураций. Вы делаете некоторое общее решение, которое покрывает какой-то процент потребностей конечного пользователя. Одна из ваших задач — предоставление средств для упрощения доработок. Те же коррелированные подзапросы нужны не просто так, а для того чтобы в существующий запрос вставить получение дополнительного поля без усложнения дальнейшего обновления. Есть СУБД которые поддерживают их нативно и вместо того, чтобы сделать либо реализацию (пусть медленную) для остальных СУБД или просто разрешить использовать ее только при доработках, вы обрубаете это возможность вообще.
Теперь ответы на вопросы:
1.1. до 8.2 была возможна следующая конструкция
СОЕДИНЕНИЕ Таблица1 КАК Строки1
ПО (Поле1, Поле2) В (
ВЫБРАТЬ ПЕРВЫЕ 1
Поле1, Поле2
ИЗ Таблица1 КАК Строки2
УПОРЯДОЧИТЬ ПО
Поле1, Поле2)
это не работало на всех СУБД кроме SQL Server. В 8.2 (видимо решили, что это унизит Oracle) эту возможность обрубили и оставили возможность использовать только одно поле.
1.2. Получение номера строки выборки:
SQL Server, ROW_NUMBER, 2005
Oracle Database, row_number() over()
IBM DB2, row_number() over()
Postgre, row_number() over()
Похоже что только на файловой нет
Еще более веселая штука, связанная с регистрами сведений. В базу добавляется поле _SimpleKey, которое является идентификатором записи регистра сведений и которое используется в механизмах платформы. Но во встроенном языке к нему доступа нет. А теперь представьте себе размер извращения, чтобы для каждой строки запроса получить последнее значение ресурса регистра сведений, имеющего несколько измерений.
2. Если вы будете продолжать делать упор на то, что производительность встроенного языка не важна — так и пишите в книге по встроенному языку — «это не язык, а скрип и необходимо минимизировать его использование. А если нужно что-то посчитать — внешние компоненты вам в помощь».
4. Именно, дошло до того, что многие разработчики, даже опытные, насмотревшись примером из ERP 2 начинают использовать временные таблицы вообще везде. Вообще это пошло еще с ЗУП 2, когда запросы на несколько тысяч строк стали нормой, опять же из-за низкой производительности встроенного языка, которая на задачах расчета зарплаты отразилась наиболее остро
Вообще на партнерке вам пишут очень много дельных предложений и замечаний, но на большинство из них идут либо «пожелание записано», либо «мы считаем что этого не нужно». По поводу «скорости» реализации пожеланий приведу 2 примера:
В 2005 году впервые подняли вопрос о необходимости использования merge при сравнении/объединении конфигураций. Данная функция появилась в 2014 (9 лет).
В тестовой версии 8.3.7 (2015 год) появилось динамическое обновление клиент/серверной базы без перезапуска конфигуратора — у нас люди плакали от счастья, хотя проблему стали обсуждать сразу после выхода платформы (2004 год)
По таким вопросам как ООП, производительность встроенного языка, развитие языка запросов должны быть постоянно открытые топики на партнерке с обсуждением всех заинтересованных сторон. Сейчас разработчики типовых конфигураций вообще не участвуют в топиках по платформе (видимо это у вас запрещено правилами внутреннего распорядка).
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. Главное что платформа это делает.