Да здравствует Logica: Google представил новый язык программирования

0. Infostart 21.04.21 15:42 Сейчас в теме
Компания Google разработала новый язык для логического программирования – Logica. В его основе – наработки запущенного ранее проекта Yedalog и языка Datalog для программирования декларативной логики.

Перейти к новости

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Darklight 27 21.04.21 17:38 Сейчас в теме
Что-то не понравилось, некрасиво совсем как-то выглядит. Хотя согласен - что язык SQL устарел и нуждается в замене. Идея с предикатами поначалу показалась здравой - но показаны примеры мне показались синтаксически очень кривыми, не шибко лучше аналогичных в SQL.
Пример с вычисляемыми предикатами вообще не понял; на самом деле вообще плохо понимаю я эти примеры:
В такой ситуации условие MagicNumber (x) должно выполняться, когда х точно равен 2, 3 или 5

Я это трактую как инструкцию логических языков типа Пролога, т.е. мы из источника данных связанного с именем MagicNumber (как связывается - это вообще отдельный вопрос сейчас не буду разбираться) должны выбрать данные, где поле x=2 или 3 или 5 - но тогда это такой запрос SQL
SEL ECT
*
FR OM MagicNumber  
WHERE X in (1,2,5)


А на языке предикатов это как раз могло бы выглядеть так
MagicNumber(x: 2)
MagicNumber(x: 3)
MagicNumber(x: 5)


или проще
MagicNumber(x: [2,3,5])-> далее обработка


А уже в теле предиката можно было бы размещать новые предикаты фильтрации/обработки отобранных данных

Но если нужно генерировать данные как

SELECT 2 AS x
INTO #MagicNumber

UNI ON ALL

SELECT 3

UNION ALL

SEL ECT 5;
Показать


То на предикатах это может быть так

MagicNumber(x) <- x=[1,3,5]
MagicNumber(x)


То есть определили один генератор через другой

для более сложных случаев можно и циклы сделать
MagicNumber(x) <- FOR i  IN [1,3,5] -> x=i;
MagicNumber(x)


Ну или наоборот короче
MagicNumber(x) <- [1,3,5]
MagicNumber(x)


Но всё это примеры слишком далёкие от реальных при работе с базами данных

P.S.
Пояснение
Такая запись
MagicNumber(x,y,z) <-
определяет предикат с полями x,y,z - определение может быть одиночным или возвращать набор данных
Может быть несколько определений предиката - все они будут объединяться (объединять данные) в рамках области определения
MagicNumber(x,y,z="bla-bla-bla") <-
Задаёт полю значение по умолчанию
Такая запись
MagicNumber(x,y,z) ->
делает выборку из уже определённого предиката и справа может быть алгоритм обработки этой выборки
А это
MagicNumber(x,y,z)
То же самое но без обработки
Такая запись
MagicNumber(x,y,z:"bla-bla-bla") ->
Накладывает просто фильтр на поле z
Фильтры могут быть и более сложными
MagicNumber(x:{IF it > 0},y:([1..10]|[-10..-1])&(it % 2 = 0),z:["bla-bla-bla","foo-foo-foo"]) ->
И они могут быть в теле обработки для комплексно-сложных случаев

Если поле, по которому идёт фильтр нужно не включать вы выборку - его можно экранировать, каким-нибудь доп. символом, наример так
MagicNumber(x,y,^z:"bla-bla-bla") ->

Последовательный вызов нескольких предикатов (как в примере в начале) делает выборку из них всех с объединением
Вот такая вот мне ЛОГИКА приходит в голову за 15 мнут размышления

P.P.S.
Пробелы по среди слов в блоках кода - это не я - это движок инфостарта слова корёжит
2. booksfill 21.04.21 18:06 Сейчас в теме
Т.е. предлагается очередная надстройка над SQL, которая сама будет решать как и что писать/читать в реальный SQL запрос?

Если да, то спасибо, но не надо.
Перестали убеждать заклинания: "да, не оптимально, но докупите еще n гигов памяти, процессорных мощностей и все залетает",
"теперь даже кухарка смогёт" .

Всегда надо думать, что оптимальней - закидать шапками или включить голову. Шапки, кажется, кончаются, начинаются метания.

Вот если бы они сделали полноценный язык работы с СУБД, полностью и полноценно заменяющий SQL, поддерживающийся ведущими вендорами СУБД , как основной, и имеющий единый стандарт- другой разговор.
Vyacheslide; +1 Ответить
3. Darklight 27 22.04.21 10:05 Сейчас в теме
(2)
Вот если бы они сделали полноценный язык работы с СУБД, полностью и полноценно заменяющий SQL, поддерживающийся ведущими вендорами СУБД , как основной, и имеющий единый стандарт- другой разговор.

Думаю, что без прохождения пути надстройки над SQL, ни один новый язык выборки данных никогда не заменит SQL на уровне СУБД.
Так же замечу, что вероятно язык разрабатывался не только как замена SQL - но и как обобщённая альтернатива для NoSQL СУБД.
Как разу Google есть своя NoSQL СУБД BigTable
Относительно недавно Google представила и NewSQL реляционно-нереляционную СУБД (наверно что-то типа SAP HANA, только с корнями из NoSQL архитектуры) Cloud Spanner - сейчас там язык SQL-подобный, но, вероятно, язык Logica туда будет со временем встроен на уровне самой СУБД, без промежуточной трансляции в SQL

Но, я не вижу особых проблем и с авто трансляцией в SQL - почему считаете что это априори неэффективно? Всё зависит от движка трансляции: насколько хорошо он умеет оптимизировать запросы, в т.ч. опираясь на статистику из СУБД и на статистику прошлых выполнений - тут преимущество именно в динамичности таких запросов - нет жёстких SQL продукций - каждый раз транслятор один и тот же запрос может изменить или взять из кеша уже готовый. Да, язык SQL не очень располагает к удобной оптимизации, да - у его на различных диалектах разных СУБД есть полно нюансов оптимизации. Отчасти транслятор мог бы и сам пользоваться этими нюансами оптимизации (если не на коленке написан; в т.ч. получая специальные метауказания-подсказки от программиста), отчасти просто забивая - бес серьёзной потери в производительности. Считаю, что не для OLTP решений трансляция в SQL не имеет серьёзных камней производительности. А в OLTP для не шибко сложных запросов (а обычно так и есть) тоже вполне себе справится. Более того, ещё и сгладит ошибки и нептиммальности составления запросов - так что в среднем будет куда более эффективно выполняться, чем если все будут писать на SQL не тратя сутки на пролёт времени высококвалифицированных SQL программистов на оптимизацию каждого запроса (и потом ещё не меньше времени на периодический анализ и переделку запросов по факту их выполнения и изменения состояния данных или нагрузки в СУБД).
Вот - язык запросов 1С - это же тоже трансляция в язык SQL диалекта конкретной СУБД - да тут транслятор слабоват - да тут мало возможностей по специальной оптимизации на уровне исходного транслируемого языка. Но работает. Нет... ну скажете, что плохо работает - и я соглашусь - просто так сделано - плохо! Можно было куда лучше сделать! Но 20 лет назад - это было вполне неплохо. А ещё через 20 лет, в будущем поколении 1С Предприятие - конечно, нужно сделать куда более продвинутый транслятор (видимо с AI анализатором в комплекте).

Вон SAP HANA - да - там свой язык и своя поддержка на уровне СУБД - работает хорошо - возможно и компания1С со временем пойдёт таким путём - хотя делать свою производительную СУБД вряд ли по зубам компании 1С - это вообще мало кому по зубам - но поживём, увидим, вероятно, если будут делать свою СУБД, то в партнёрстве с именитыми компаниями - хоть с той же Postgres Professional. Но отказываться от поддержки MS SQL Server и Oracle СУБД - было бы самоубийство - поэтому для своей СУБД могу сделать прямую поддержу своей системы запросов, а для других - как сейчас - трансляцию в SQL (главное лучше, чем сейчас - но этот опыт "набьют" при создании своей СУБД)
4. booksfill 22.04.21 17:48 Сейчас в теме
(3)
Но, я не вижу особых проблем и с авто трансляцией в SQL - почему считаете что это априори неэффективно?


Все просто: если Logica = эффективности SQL + кардинально упрощает жизнь, то нет никакой необходимости в промежуточном SQL. И ваш же пример с "SAP HANA" это подтверждает.
А если Logica рождает нечто "нормальное в 80%" случаев, то уже в 99% случаев будут докупать железо и/или терпеть тормоза.

По опыту 1С - хорошо если 1% заморачивается (причем когда пониже спины клюет уже стадо жареных петухов) хотя бы просмотром того, во что 1С превращает "простой" запрос, скажем к регистратору составного типа. И появляются великие откровения типа использования "Выразить".
Я думаю, что мало кто допустил бы подобную ошибку, если бы самостоятельно сооружал многокилометровый запрос,
а ведь язык запросов 1С вовсе не запрещает писать то тот самый километровый, но приятно так маскирует. :)

Я вовсе не сторонник "копания в ассемблере" - все, чего хочется, так это того, чтобы любая надстройка,
не важно как ее назвать Hibernate, Logica, давала те же возможности, что дает сейчас SQL + облегчала жизнь.
И не вижу причин почему этого нельзя сделать абстрагируясь от вида СУБД.

P.S.
И по поводу 1С - я, возможно ошибочно, понимаю язык запросов 1С как обычный ORM, но мне непонятно, почему его практически не развивают, хотя бы в самых насущных аспектах. Не думаю, что в 1С не понимают, что без секционирования, возможности нормальной работы с индексами и т.д и т.п., работать с большими системами печально уже сейчас.
Возможно можно надеяться, что готовится что-то серьезное.
5. Darklight 27 23.04.21 10:59 Сейчас в теме
(4)
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 лет хорошо работает, так и трогать её не нужно, а кто жалуется – просто «не умеет её готовить»!
6. booksfill 23.04.21 16:00 Сейчас в теме
Да, согласен я с тем, что "приходится в SQL" (просто написал, чего хотелось бы видеть в идеале).
Но абстракция, построенная на нижележащей, должна давать минусов меньше, чем плюсов.
Мне кажется, что этот язык (вообще-то напоминающий набор обычных шаблонов)
минусов дает больше. Хотя бы потому, что не освобождает от изучения SQL, требует затрат времени на свое изучение, и провоцирует на написание потенциально неэффективного кода.

Что касается микросервисов я в этом очень плохо разбираюсь.

Насколько я понимаю, есть два варианта:
1. Создать обычный сервер, дать ему доп. канал "общения" например, по http и обозвать его микросервисом. Яркий пример, из тех, что мне встречался в статьях - сервер рассылки спама. Вполне обычный сервер, с достаточно сложным функциналом.

2. Честно раздробить функционал на достаточно атомарные порции и попытаться работать со всем этим зоопарком.
Но тут возникают крайне неприятные вопросы, про отслеживанию работоспособности, авторегистрации и автопоиска сервисов,
поддержки зоопарка языков, надежности межсетевого взаимодействия, синхронизации, безопасности каналов, использования микросервисов от сторонних производителей, соотв-но и зависимость от них, и т.п.

Начинают плодиться шины данных, отдельные сервера взаимодействий и авторизации, агрегаторы данных ...
Чтобы замаскировать масштаб катастрофы все это называется модным понятием "стек технологий".

Вместо 1-2х точек отказа появляются десятки, хотя бы даже с точки зрения железа, соотв-но всплывают проблемы отказоустойчивости, которые, в свою очередь, тянут свой стек технологий.

P.S.
Значит берегут силы и финансы для нового крупного рывка

Хотелось бы надеяться, но 1С понял это еще лет 15 назад и тайком что-то плодит, но верится с трудом.
Иначе где инсайд?
7. Darklight 27 27.04.21 12:11 Сейчас в теме
(6)
просто написал, чего хотелось бы видеть в идеале

Да по сути, Вы ничего не написали - ваше желание сравнимо с утверждение - "только SQL - только хардкор" - т.е. Вы хотите SQL, но, с одной стороны не вроде бы не против его расширения, с другой - против расширения для упрощения синтаксиса в ущерб эффективности (против синтаксического "сахара", который в неумелых руках может снижать эффективность)!
Но я Вам скажу - даже ANSI SQL в неумелых руках легко позволяет писать крайне неэффективные алгоритмы - а уметь писать на нём сложные эффективные алгоритмы - это искусство для настоящих мастеров! Коими большинство программистов баз данных совсем не является!
Чего только стоит то, что нужно правильно соблюдать порядок полей в условиях - чтобы применились индексы. Да - это старая проблема - да - некоторые СУБД её умеют сами оптимизировать. Но... IBM DM2 не умеет, PosgtreSQL не умеет. И 1С Предприятие 8 это знает - поэтому сама правильно переставляет условие при трансляции своих запросов в SQL.
Но это я привёл самый простой пример - а таких в SQL ещё тьма! Взять хотя бы оператор "IN" для небольших дискретных выборок - большинство СУБД так же не умеют его оптимизировать в набор нескольких условии на равенство (и 1С Предприятие 8 тоже) - а для них это чаще эффективнее (когда есть индексы), чем формирование отдельной временной таблицы с этими значениями. И многие ли программисты будут оптимизировать "ГДЕ Код В (1,2,3,4,5)" превращая его "ГДЕ (Код = 1 ИЛИ Код = 2 ИЛИ Код = 3 ИЛИ Код = 4 ИЛИ Код = 5)" (не все СУБД это умеют оптимизировать, а 1С в любом случае сделает временную таблицу). Это я не говорю о том, что зачастую (при наличии индексов) - запрос будет ещё быстрее - если его разбить на несколько объединений - писать руками - это просто кошмар!


Но абстракция, построенная на нижележащей, должна давать минусов меньше, чем плюсов

Конечно плюсов должно быть больше. Но полностью исключить минусы вряд ли удастся. Да и минусы и плюсы - имеют разный вес в зависимости от области применения таких абстракций. Где легче и быстрее писать код с меньшим числом ошибок (и какой код будет понятнее), на С++, Rust, С, C#, Python, 1C? Каждому языку - своя область применения.
Про минусы LOGICA пока сложно судить - с ней нужно лучше разобраться. Но пока я не смог оценить даже её плюсы. Но... это не значит, что идею нельзя довести до ума - минимизировав минусы, добавив плюсов.

Что касается микросервисов я в этом очень плохо разбираюсь

Микросевисы 1С-нику проще воспринимать как удалённые процедуры сервера, вызываемые с клиента (даже без всяких там web/http сервисов, хотя можно ещё REST API упомянуть - но это будет слишком простой микросервис). Смысл микросервиса - Вы вызываете с некими параметрами для (возможно) некоторых данных - он их обрабатывает - и возвращает ответ (возможно результат). Микросервисы в СУБД в простейшем виде - это хранимые процедуры. Отчасти микросервисами (но не фактически) можно считать виртуальные таблицы 1С. Реально - сейчас в ряде СУБД можно писать вообще свой код обработки данных (например для MS SQL Server можно писать алгоритмы на платформе .NET) - а потом обращаться к ним прямо из SQL синтаксиса - как к функциям (например, можно написать свою агрегатную функцию) или как источникам данных (с параметрами, как хранимые процедуры, но с большими возможностями). Если будет стандартная библиотека работы с бизнес-сущностями 1С ИБ - то можно писать очень интересные микросервисы обработки таблиц прямо в СУБД - вот об этом и речь. В идеале - можно вне микросервисов вообще отказаться от SQL запросов - перейдя на декларативный подход к выборке (и изменению) данных - вызывая такие алгоритмы прямо на СУБД - передавая им декларативные настройки этих выборок. А возможности микросервисов на СУБД куда шире, чем возможности клиентов СУБД. А если чего-то будет не хватать - просто пишете свой микросервис - и используете его с клиента (или с сервера приложений).

Микросервисы - что Вы имеете в виду далее - это уже отдельные (условно) автономные сервисы - как отдельные приложения. Их плодят как раз для того, что их проще разрабатывать и обслуживать. Ими проще управлять (даже несмотря на то, что их много) - их проще балансировать и распределять запросы между ними, в т.ч. при их падении. И они очень хорошо распараллеливаются (т.к. изначально так разрабатываются). Но всё-таки, говоря о SAP HANA я имел в виду другие микросервисы - встроенные в СУБД - но с наружи они выглядят как и все другие микросервисы - у них общий подход к работе с API - что так же упрощает взаимную интеграцию.

Хотелось бы надеяться, но 1С понял это еще лет 15 назад и тайком что-то плодит, но верится с трудом.

15 лет назад 1С ещё только только перешла на кластерную архитектуру и работала над управляемым приложением. То есть развивала ещё совсем молодую 8-ку. Но в последние лет 5 они занимаются развитием мобильного приложения и думают как раз о микросервисной архитектуре (таковой доложена была быть платформа 8.4 но её отменили). Так что микросервисы припасены для более серьёзного революционного перехода, которого боятся на верхах компании 1С. Пока 1С Предприятие 8 развивается медленно и эволюционно. Никаких анонсов о разработке принципиально новой платформы нет. Видимо ещё не время. Поэтому я прогнозирую революцию не ранее 2040 года - да и то, возможно к тому сроку только официальный анонс сделают, а на разработку финального коммерческого релиза уйдёт ещё лет 10-15. Но это не значит, что в компании 1С не ведут теоретическое проектирование того, что хотелось бы создать в будущем. Нет смысла выкатывать сейчас что-то похожее на 1С Предприятие 8 - выдавая за совершенно новый продукт, который срочно всем надо купить.1С Предприятие 9 - должна стать принципиально новой платформой, а не развитием 8-ки. И должна быть заметно более привлекательной - чтобы её захотели купить не единицы, а миллионы потребителей
8. booksfill 27.04.21 18:22 Сейчас в теме
Спасибо про разъяснения по микросервисам, я правильно понял, что одним словом назвали множество сильно разных технологий c "Общим подходом к API" ?

"Честное слово, я и не подозревал, что вот уже более сорока лет говорю прозой." (С. Жан Батист Мольер).
Оказывается, я уже много лет использую микросервисы, причем даже на "высоком идейном уровне",
т.к. делал работу офиса на 120 менеджеров с облачной телефонией, как раз на основе REST API.
Даже еще до того, как появилось слово "микросервис". :)

Что касается "это уже отдельные (условно) автономные сервисы", я плохо понимаю, когда их имеет смысл использовать. Кажется, исходя из тех проблем, о, которых я писал ранее - проглядывают уровни очень больших компаний. Нет, использовать могут и небольшие фирмы, но минусов, по-моему, они получат куда больше. Ибо затраты будут несопоставимы с полученным эффектом.
Оставьте свое сообщение
Вопросы с вознаграждением
Вакансии
Архитектор 1С
Москва
зарплата от 200 000 руб.
Полный день

Администратор 1C
Москва
зарплата до 110 000 руб.
Полный день

Консультант-аналитик 1С
Москва
зарплата до 180 000 руб.
Полный день

Программист 1С
Москва
зарплата до 160 000 руб.
Полный день