()
Logica = эффективности SQL + кардинально упрощает жизнь, то нет никакой необходимости в промежуточном SQL
Как Вы не понимаете, промежуточный SQL нужен не для эффективности - а для совместимости. Сейчас практически все реляционные СУЬД базируются на SQL языке обработке данных (да ещё и наплодили кучу проприетарных диалектов). И ни один новый язык не сможет раз - и потеснить прижившийся за десятилетия язык SQL. Вот, даже, NoSQL СУБД, которые принципиально абстрагировались от ущербного SQL (зачастую заменяя его не менее ущербными прориетраными многочисленными реализациями новых языков) - сейчас снова возвращаются к SQL (пусть и к некоему подобию) - взять хоть Yandex ClickHouse или уже упомянутый Google Cloud Spanner. И делают они это не из-за любви к SQL.
А потому, что программисты к нему привыкли - сейчас SQL - это де-факто универсальный стандарт обработки данных. Поддерживаемый, очень большим числом СУБД, включая некоторые NoSQL.
И вытеснить SQL даже за десятилетия - это непосильная уже задача.
SAP HANA - это всё-таки несколько иное - в SAP R3 вообще прямые SQL запросы как-таковые отсутствуют (там что-то такое же как в 1С - но внутри да - есть свой унитарный механизм запросов SAP - которые транслируются в запросы СУБД).
В SAP HANA эту идею развили глубже - так как теперь там и СУБД стала проприетарная. Вот как раз в этом случае да - можно и не поддерживать SQL - а сразу везде поддерживать исключительно новый язык напрямую - т.к. и СУБД уже для этого разработана (и другой быть не может) и программисты изначально уже приучены к отсутствию прямой поддержки SQL.
Если бы компания 1С для 1С Предприятие 9 разрабатывала свою проприетарную СУБД - то да, можно было бы сразу внутри делать свой проприетарный (ну или взять какой-то иной - ту же LOGICA) язык запросов - чтобы уйти от морально устаревшего SQL. Но как бы хуже не вышло:
Вон, в 1С 7 - был язык проприетарный запросов - от которого все плевались - и да - он был плох, но это не значит, что его нельзя было доработать до более эффективного и удобного использования, оставив базовый синтаксис
Вон, в 1С 8 - переделали на SQL-подобный язык но тоже, в общем-то, проприетарный и транслируемый - поначалу народу понравилось, но потом, опять стали плеваться - но это, скорей, потому, что язык запросов в 1С Предприятие 8 почти не развивался (и если и развивался - то очень сдержанно под давлением общественности и иных обстоятельств) - за это время диалекты SQL в других СУБД сделали большие рывки вперёд - вообще много чего появилось в СУБД за 20 лет существования платформы 8 (от ранних бета и альфа версий) - впрочем тут и язык разработки программного кода тоже не шибко эволюционировал. Но главное - за это время все недостатки ущербной простой модели языка запросов 1С стала очевидна почти всем.
Добавлю, что уже говорил, даже если компания 1С выкати для 1С Предприятие 9 свою собственную проприетарную СУБД - она вряд ли сможет отказаться от поддержки нынешних основных СУБД - т.к. превзойти их разом компания 1С не сможет даже с партнёрами (ну разве что выйти на уровень PostgreSQL, просто взяв её ядро за основу), да и куплены они уже у многих клиентов - переходный период должен быть плавным. Это не компания SAP с её колоссальными возможностями (да и у той - переход c SAP R3 к SAP HANA не завершён до сих пор - обе системы существуют параллельно).
Лично мне, более симпатизирует модель обработки данных SAP HANA - на её основе я бы предложил язык и для 1С Предприятие 9 (идей много) - главная суть - вообще отказаться от языка запросов - перейти к пакетной объектной модели - через классы объектов заполняются требования к выборке и обработке данных - затем они оптимизируются и отбавляются в СУБД на выполнение (для поддержки классических СУБД - происходит трансляция в пакетный SQL запрос). А на СУБД тоже больше возможностей по обработке - начиная от возможности размещения там хранимых процедур - но это уже прошлый век. Сейчас же рулят микросервисы - в т.ч. выполняемые прямо в СУБД, наспанные на специализированных языках, поддерживаемых этими СУБД - вот эти размещённые в СУБД алгоритмы и должны производить сложные действия по обработке данных. Те самым исходные запросы-требования в большинстве случаев должны быть достаточно алгоритмически-простыми. Так же на микросервисы должна быть вынесена большая часть алгоритмов контроля, мониторинга и конвертации данных - чтобы платформе бизнес приложения об этом не приходилось думать. Вот как писать эти микросервисы - это уже отдельная задача. У SAP HANA это JavaScript - а 1С умеет транслировать свой код в JavaScript - это просто намёк на то, что писать микросервисы можно в основном привычном синтаксисе языка разработки - а далее - он мог бы, транслироваться в поддерживаемые языки целевой СУБД (например у MS SQL Server - это "язык IL" - т.е. байт-код платформы .NET) - но у разных СУБД могут быть разные не то что языки - разные возможности этих языков и разные библиотеки - это самая большая проблема - так что писать микросвервисы, видимо нужно индивидуально для каждой СУБД. Ну, а в платформе 1С уже должно быть встроено множество микросервисов и их количество постепенно должно расширяться.
Вот в такой модели, в общем-то, и языка запросов то уже нет - с клиента идут обектные, скорее декларативные описания требований, а на СУБД идёт вызов микросервисов на специальных языках).
Это не только мой мнение - некоторые другие эксперты уже тоже прогнозирут именно такое будущее развития программирования в СУБД.
И Google LOGICA тут, видимо, тоже готовится к тому пути развития. Но пока - ему без трансляции в SQL никак не обойтись - но это переходный период.
во что 1С превращает "простой" запрос, скажем к регистратору составного типа. И появляются великие откровения типа использования "Выразить".
В этом и проблема SQL-подобных транслируемых языков
1. С одной стороны они упрощают жизнь программиста - и правильно делают, т.к. сложность бизнеслогики растёт - и писать многокилометровые запросы просто не эффективно. А главное, чревато ошибками - в которых потом будет сложно разбираться - так что это палка о двух концах.
2. С другой стороны - некоторые мощные фишки языка действительно могут оборачиваться проблемами - но, тут скорее две ситуации:
а. Это недостаток синтаксиса языка - позволяющий просто написать неоптимальный код, и сложно оптимальный - тут можно поработать над синтаксисом - чтобы выставить баланс на двух чашах весов. В частности синтаксис "ВЫРАЗИТЬ" просто очень неудобен в использовании. А прямое обращение через точку - наоборот удобно. С последним пока я не знаю как сделать так, чтобы усложнить жизнь, не превратить её в ад. А с первым да хотя бы такой синтаксис как
"ВЫРАЗИТЬ(Регистратор КАК Документ.{ПриходныйКассовыйОрдер, РасходныйКассовыйОрдер, ПлатежноеПоручениеИсходящее, ПлатежноеПоручениеВходящее}).СчетРассчетов"
уже сильно упростило бы жизнь. А если виды метаданных можно было бы объединять в группы - так вообще круто было бы
"ВЫРАЗИТЬ(Регистратор КАК ГруппаПлатежныхДокументов}).СчетРассчетов".
А ещё круче - это поддержка интерфейсов, и с ещё более простым синтаксисом
Регистратор:ПоддержкаРасчетов.СчетРассчетов.
Иным подходом могли бы стать объекты как "View" (или хранимые процедуры) - ну суть та же - заранее ограничить набор возможных типов составного типа в источнике.
б. Это недостаток отсутствия встроенного анализатора возможных ошибок - IDE нового поколения должны больше следить за кодом программиста и выявлять проблемные места и сигнализировать о них. Как сразу. Так и потом - автоматически собрав планы выполнения проблемных алгоритмов и выкатив их в отчёте с предложениями по их улучшению.
Кстати, описанные в пункте а. подходы к решению проблемы хороши и для системы анализа - просто платформа проводя постоянный мониторинг выполнения запросов и выявляла бы и желаемые индексы, и желаемые группы, и желаемые приведения к сокращённым составным типам и т.п. – и информировала об этом программиста (по и идеи даже не программиста, а специалиста по техническим вопросам и оптимизации клиент-серверного взаимодействия – а он уже передавал бы задачи программистам на конкретные доработки, ну или выполнял бы их сам).
Ну а, что касаемо составных типов - особенно документов - особенно регистратора - вот тут как раз всякие "ВЫРАЗИТЬ" не часто является подходящим решением - т.к. нужна обработка всех документов, в т.ч., возможно, появляющихся позже. Вот поэтому выше я и предложил более удачны решения - где фильтрация выносится за пределы запроса - и является задачей общей архитекторы.
А если система запроса и обработки данных становится более декларативной – то ту вообще возможностей по анализу, совмещённому с постоянной оптимизацией, в руках платформы очень много – в идеале – она сама могла бы выявлять узкие места и устранять их (не все, но хотя бы часть).
Я вовсе не сторонник "копания в ассемблере" - все, чего хочется, так это того, чтобы любая надстройка,
не важно, как ее назвать Hibernate, Logica, давала те же возможности, что дает сейчас SQL + облегчала жизнь.
И не вижу причин почему этого нельзя сделать абстрагируясь от вида СУБД.
Я понимаю Ваше желание, но понимаю, что это практически невозможно - потому что это как раз сродни возврату к уровню ассемблерного программирования с необходимостью поддерживать диалекты разных платформ выполнения, да ещё и в постоянно меняющейся архитектуре этих платформ. Это уже пройденный этап – развитие так идти не будет (хотя, вот в вебе наоборот – набирает популярность Web Assembler – но это особый случай, и он клиентский, а не серверный). Основное программирование сейчас движется в сторону управляемых приложений (когда их выполнением управляет внешняя платформа) – где за счёт жертвы производительности (небольшой жертвы – т.к. средства оптимизации постоянно улучшаются, а накладные расходы сокращаются) ускоряется процесс программирование и минимизируются ошибки. Всё это итоге снижает издержки бизнеса и повышает масштабирование. Так что да – зачастую проще и дешевле вложиться в апгрейд железа – чем постоянно вкладываться в исправлении ошибок, оптимизацию и перестройку программного кода. Тем более с тенденцией к переходу на программирование параллельной обработки данных – код становится сложнее, его оптимизация и устранение ошибок тоже – а вот масштабирование параллельного кода – наоборот становится дешевле.
С вашим постскриптумом я полностью согласен. Подозревая, что развитее отсутствует в угоду упрощения программирования - такова была политика Бориса Нуралиева ещё со времён 1С 7 и активно позиционировалась вместе с 1С Предприятие 8 – программировать на этой платформе должно быть так легко – чтобы справился даже бухгалтер (как он и справлялся ещё в Бухгалтерии 5 и на 1С Предприятие 6) – но это, так и осталось иллюзией. А сейчас наоборот БСП и типовые конфигурации стали очень сложны в сопровождении и оптимизации именно из-за ущербности языков и устаревших концепциях архитектуры программного кода. Но что-то принципиально менять – это революция (эволюцией уже не обойтись) – а этого Борис боится больше всего (как и большинство людей пред пенсионного возраста) – и его понять можно – переходы 1С 7 -> 1С 8 и 1С 8.1(2) -> 8.3 TAXI (и даже ПРОФ -> КОРП) были очень болезненными и для сообщества, и для компании 1С – поэтому то, до сих пор и нет ранее анонсированный (ныне забытой) 1С 8.4. Поэтому – если и будет революция – то уже в 1С Предприятие 9 – лет так через 20, когда старые управленцы в 1С уйдут на пенсию – а конкуренты уже будут совсем на другом уровне технологий! А пока 1С в России и так хорошо продаётся. А на запад (как и на восток) в нынешнем виде и обстановки выйти никак не удаётся. Значит берегут силы и финансы для нового крупного рывка. Ну или просто сольют подразделение компании – когда платформа устареет настолько, что большинство потребителей будут предпочитать конкурентов (коих в России то и нет почти), а до этого момента будут создавать видимость плавного консервативного развития – ведь в стане 1С сообщества не мало таких же консерваторов, считающих, что 1С Платформа 8 может и не идеальна – но ведь уже почти 20 лет хорошо работает, так и трогать её не нужно, а кто жалуется – просто «не умеет её готовить»!
