Третья часть Заруба 1С vs lsFusion — 3

Коротко содержание первых трех частей

На 1С все написано
Потрачено порядка 25 часов
База http://server.odinesnik.ru/1cvslsfusion/

Фузиновцы вместо реализации по поставленным функциональным требованиям пишут что-то непонятное
С их слов это будет похоже на Odoo, но лучше, и при этом будет полностью покрывать поставленные функциональные требования
Если я все правильно понял, то участие в зарубе в конце концов принимать отказались, то ли по причине того, что им не заплатили, то ли по какой-то другой причине, непонятно
База, в которой пишется клон Odoo https://demo.lsfusion.org/mycompany/

Ниже на всякий случай перечисляю ранее озвученные в OFF: lsFusion vs 1C. Раунд 3 критерии (пусть даже часть из них субъективные, а что делать):
— Скорость разработки (более чем адекватный критерий, заказчику это очень важно)
— Читабельность кода (еще один важный критерий, решение нужно поддерживать)
— Функциональность (опять же важно, потому что заказчик хочет удобства, а не велосипед на костылях)

Ну что, засчитываем Фузине техническое поражение и расходимся?

(785) еще раз. интересует, как сработает constraint. в каком виде он попадет на SQL сервер? и в каком виде на SQL сервер попадает та же проверка, в условиях, когда мы по какой-то причине добавили N условий, при которых она срабатывать не будет?

что с ним будет?
1) запрос с проверкой условия, а потом, если оно не выполнилось запрос на изменение данных? тогда чем это принципиально отличается от 1С?
2) запрос с множеством условий, из-за которых итоговый набор данных для изменения будет пустым?
можно упрощенно, псевдокодом.

(786) Сначала проверяются ограничения, потом обновление всех данных. Отличается тем, что эти SQL запросы не надо писать вручную, как запросы на тысячи строк в УТ, а делается одной строкой. И в 1С появилась прозрачная материализация данных (типа MATERIALIZED VIEW в Oracle или MATERIALIZED в lsFusion) ?

а вот это
[Неэффективное получение данных объектов

Так как несвоевременное или избыточное чтение данных с сервера БД и передача их на сервер приложений может приводить к существенному падению производительности, обычно ORM-фреймворки предоставляют разработчику целый набор инструментов по управлению получаемыми ими данными. Но не 1С. В 1С объект читается всегда целиком, в том числе с табличными частями, но не более того (без каких либо связанных данных). Как следствие, данных читается:

либо слишком много — если надо получить только одно поле (реквизит)
либо слишком мало — если в цикле надо обращаться к другим объектам по ссылке, мы получаем классическую проблему N+1 (один запрос для получения N объектов и по одному запросу для каждой ссылки).]

Можно мне перевести вот это? Где они рассмотрели проблему N+1 в запросе? А то что в цикле не надо получать из ссылки данные через точку, любой дурачек знает.

(779) "например виды цен в "типа ERP")" -ыыыы. конструктив так и прет)))

(787) я уже тебе все написал, про ваш MATERIALIZED и невозможностью управлять итогами в фузине, а ты благородно слился.

(788) Объектная модель в 1с используется совсем для другого, хотя кому тут объяснять.

(790) Все там можно управлять. Пиши любое выражение и вешай MATERIALIZED и платформа все сделает сама.

(791) Так про это и было в статье, что в 1С недоORM и в жизни приходится писать на плоском SQL, как в 90е.

(787) вот опять.
1) запросы на тысячи строк в УТ обсуловлены совершенно не сложностью 1С или необходимостью их писать.
2) если хочется "одной строкой", то я могу эту проверку загнать в отдельную процедуру и тоже вызывать ее одной строкой.
ну не является это преимущством, поймите.

нужно понимать, что
а) в случае, если бизнес логика подразумевает много условий для проверки/не проверки отрицательных остатков, важно, чтобы можно было реализовать это быстро. в вашем варианте, когда к конструкции constraint добавляются и добавляются новые условия, при этом все эти проверки сработают при ЛЮБОМ апдейте таблицы, это не очень удобно.
б) важно понимать итоговую скорость работы, с учетом всех этих ограничений (т.е. чтобы не было резкого проседания производительности после добавления еще одного условия). Тут, мне пока не очевидно, что у вас это будет работать именно так, как я ожидаю.

"И в 1С появилась прозрачная материализация данных (типа MATERIALIZED VIEW в Oracle или MATERIALIZED в lsFusion) ?"
Это к чему? Какую задачу (пример) мы решаем? Что мы этим сравниваем? В 1С можно реализовать то что вам нужно, но возможно не так удобно как у вас. Но мы опять скатываемся к сравнению двух платформ на частных задачах.

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

(792) невозможно в фузине хранить итоги и управлять датой начала хранения итогов - факт. Любой аналитический запрос на два три года назад уложит систему - факт. Вообще никакого управления итогами, кроме как указания того, что вот по этим штукам надо их хранить.

(794) Почитайте статью. Там все написано. И аргументация как всегда. Могли в УТ не писать тысячи строк, но написали.

(795) Закрывайте. Я надеюсь, что вы когда-нибудь начнете реализовывать действительно сложные проекты, как те, которые делает ЛюксСофт. Тогда у вас откроются глаза на реальность и незаменимость lsFusion.

(797) ага, оптимизацию разработчик может и не делать, а лепить проверки везде где нужно и нет, как в фузине.

(793) покажи подобный запрос на фузине)

(796) Возможно в фузине хранить итоги и управлять датой начала - факт. Любой аналитический запрос на два три года назад уложит систему в любой OLTP системе будет работать долго - это факт. В фузине будет быстрее, так как это делается на плоском SQL.

(797) ты даже после того как я тебе разжевал и положил, нихрена не понял

(800) Какой именно ? CONSTRAINT currentBalance () < 0;

(803) гут...
он разворачивается в запрос?

(801) брехня, даже в вашей сраной статье пишите что это не нужно

(801) Только в той статье вы не знали, что оказывается ими можно управлять и думали что 1с хранит все полностью.

Какие еще итоги в фузине ? Они примитивный склад с 2-мя документами осилить не могут

(804) Да, конечно.

(801)  Любой аналитический запрос на два три года назад уложит систему в любой OLTP системе будет работать долго - это факт
представляешь, а в 1с отработает быстро

(807) https://demo.lsfusion.org/erp/

(810) эту недоподелку лучше не показывайте, никому..
2*2=5, забыли ?

(809) Правда ? А какого хрена у PR на 100К он 30 секунд формируется ?

(809) Это потому что 1С устаревшее говно, любая современная импортная система будет тормозить

(811) Мы не показываем. Мы ее внедряем. И все клиенты счастливы и с радостью переходят с 1С на нее.

(808) т.е. по сути вы просто сократили синтаксис языка запроса и выставляете это как конкурентное преимущество?
Я просто находил на инфостарте подобное для 1С. Там типа запрос через функциональщину.

(815) Нет. Вы вообще не пишите SQL запросов на фузине. Там другая логика задания всего. Все строится на функциях, которые затем сами компилируются в SQL запросы. И все это сразу встроено в логику отображения.
Вот тут описано сравнение :
https://habr.com/ru/company/lsfusion/blog/458774/

Где в 1С есть CONSTRAINT'ы ? Где прозрачный MATERIALIZED :
https://habr.com/ru/company/lsfusion/blog/459066/

(814) врешь же

(816) Я ж и говорю, что сделали обертку над sql.
Вот есть пример:
https://habr.com/ru/post/122827/

(812) а передергивать обязательно? Это такой способ прикрыть некомпетентность? Я говорю про базы которые живут несколько лет. И в 1с, она возьмет ближайшую дату рассчитанного итога и опираясь на нее рассчитает старый остаток. А в фузине вы берете текущий остаток и от него считает.
А уж если рассматривать "большой и сложный код" в УТ. То там все еще более умнее чем в фузине. Вот нажал пользователь случайно проведение старого (10 лет назад) документа или может они перепроводят добрую тысячу документов, просто перепроводят ничего не меняя. Что будет делать глупенькая фузина в данном случае, для каждого из них рассчитает остаток, т.е запустит проверку. А умная 1с проверит то что было до с тем что стало после и если изменений нет, пойдет дальше.

(814) А как они рады, что система допускает неверную арифметику, и ошибки в документе 100к строк можно найти только приииииииистальным всматриванием:)

(818) А 1С тогда сделала обертку над C++.

(819) +причем как я понимаю, программист на фузине даже повлиять на это не сможет, кроме как отключением контроля остатков

(819) В фузине можете сделать просто GROUP SUM хоть на каждый месяц или год с MATERIALIZED и считать потом по ним. Но опять же вы придумываете дурные случаи ? На практике, никому не нужен остаток 10летней давности. Только аналитикам - а у них есть BI, который в разы быстрее работает. А нагружать OLTP лишними пересчетами и вешать туда аналитиков - это идиотизм.

(823) вот и хренто что это ложится на плечи программиста и это делается уже на уровне логики приложения, а не платформы.
[ На практике, никому не нужен остаток 10летней давности], большая нагруженная система даст вам в рамках года даст вам растянутые итоги и не контролировать на уровне платформы, дату хранения итогов в данном случае смерти подобно, т.е любая работа в рамках квартала-двух, а такое часто бывает, превращается в фузине в муку, а в 1с, достаточно грамотно следить за итогами и все.

(819) Откуда вы знаете, как сделано в фузине, тупее или умнее? Cпросите у Bro в соседней ветке с конкретными вопросами, он вам расскажет может быть.

(821) Ну это все же другое.
На С++ они написали интерпретатор для своего языка. Вызовы 1с не переводятся в вызовы С++. А у вас просто конструкция, которая переписывается на другой язык и отправляется в СУБД.

(826) На 1С, кстати, тоже такая же конструкция. Только копировали ее не лаконично, а прямо в таком же виде, как и сами запросы. Ну и ограничили запросы только селектами.

(825) прочитай (753)

(825) т.е вы как разработчики не знаете как работает ваш инструмент, хотя прямой контакт с разработчиком платформы даже есть?

(828) Опять же, вы не поняли, что автор статьи все прекрасно понял.
(829) Я - разработчик платформы. В данном случае я просто отправляю к тому, кто знает эту конкретную вещь лучше всех.

(830) т.е ответа от вас можно не ждать или вы не уверены?

(831) Ответа на какой вопрос?

(814) И все клиенты счастливы и с радостью переходят с 1С на нее

в списке внедрений написано, что параллельно с 1С продолжают работать, заменяя на складе древнее говно мамонта типа самописки на Access

(814) Внедряют.. да уж, с 89 года не осилить остатки по складу, печалька.

http://pics.rsh.ru/img/1_b8sovgsi.jpg

(832) умнее в фузине или нет

(833) Точно. Давно же не писал. 1С - только для бухгалтерии и ЗУП. А мы туда не лезем - экономически нецелесообразно.

(834) Вот поставил защиту от таких в зарубе, так полезли в ERP. Никто таких цифр не вводит. А если вводит, то наоборот хорошо - сразу увольняется такой сотрудник как непрофпригодный. Так что вредно такие защиты ставить.

(835) Отвечу, но чтобы это сделать с нормальной аргументацией мне понадобится куда больше времени и мотивации это делать.

(837) никогда пользователей живых не видели? бывает...

(836) напишите хоть одну реальную компанию, которая с 1С перешла на вашу поделку, выше один из ваших писал, что нет таких.

(837) в зарубе вы ничего не поставили. У вас можно продать товар, который еще не пришел

Т.е учет вы никакой не ведёте, так ?
И решений работающих, нема ?

(838) а тут да или нет. Анализирует фузина факт числового изменения показателя или нет

(840) Я на верхний склад не ставил ограничений для теста. Включил и для СНГ ограничение.

(795) они за тридцать лет не родили ничего сложнее двух табличек в экселе, а вы хотите что бы они доросли до сложных проектов? у них мышления не то. они тупо кодеры,а не программисты

(841) Ведем очень классный учет и клиентов куча :
https://luxsoft.by/klienty/

(839) Ну потому что на 1С работают только бух и зуп у нас. Но допустим в том же Гиппо мы склады (которые вели в бухгалтерской конфигурации) перевели на фузину.

(812) ну ты еще и обижаешься что говорят тебе что ты дебил?) тебе за запросы, ты за сто к строк в запросе)))

(814) это те которым вы пиздите за 1с в 1000 элементов не может? та забирайте таких тупых клиентов. фузина их уровень)

(823) групп сум?)))) бля, да ты не дебил, ты имбицил.

(830) что понял автор статьи? судя по тексту, он 1с изучал по картинкам. Большая часть бред сивой кобылы то ли от некомпетентности то ли от желания обмануть аудиторию

(836) экономически нецелесообразно потому что вы сложнее приход расход остаток не реализуете в своей платформе)

а тут https://habr.com/ru/company/lsfusion/blog/459066/#comment_20407597
смотрю толерантное сообщество зарубило братишку

а вот и реакция на сказочки от бро
https://habr.com/ru/company/lsfusion/blog/459066/#comment_20407919

Ну и добивочка
https://habr.com/ru/company/lsfusion/blog/459066/#comment_20409613

И вопрос, а куда вы лезете?)

(853) (854) это хабр, детка))) там можно обсирать только 1с. а он покусился на святое - оракл)))

(854) а вообще они там отжигают - "область применения lsFusion практически полностью совпадает с областью применения Oracle " )))))))))) ржал как конь. Узнаю Братишку))) чет вспомнил Зеленого слоника))))

ну вероятнее всего вектор пиара был нацелен на Oracle, но потом сменился на 1с

(857) "Замечание про «тысячу индусов» оставим на вашей совести, она у вас видимо большая." что там краш блеял о конструктивном диалоге?)

(857) "Точно также как я не готов обсуждать концепции вашего продукта, вы не готовы обсуждать концепции Oracle (и не надо этого делать). Спорный абзац в статье рекомендую переписать или убрать вообще. О" - ыыыыыы. они обсирали оракл по тому же принципу - мы открыли картинки глянули нифига не поняли и написали статью о том, как оракл писали тысячи тупых индусов. "мы за конструктивный диалог" дебилы, блять (с) бро

(842) ограничение будет проверяться только для измененных значений, если вопрос только в этом

Почему фузины никогда не будет в топ 30 сетей в России https://habr.com/ru/company/X5RetailGroup/blog/474770/

Но САП это трэш ещё тот, конечно...

(861) не с таким интерфейсом не взлетит. Хотя погодите...

(862) Да, фузина только убогим интерфейсом с САП и схожа...

(826) Согласен, что аналогия 1С-С++ - неправильная. Более похожий аналог (хоть и все равно не очень), что тогда язык программирования С - это обертка над ассемблером (ну или машинными кодами, как угодно). А суть в том, что часть логики, описываемой на lsfusion в конечном итоге транслируется в SQL.

Разница между тем, что сделано в lsfusion, и тем, что сделано в 1C (или в примере с хабра, который вы приводили) в уровне абстрагирования. То, что есть в 1С, можно назвать диалектом SQL, то есть вы все равно работаете в терминах таблиц, полей, соединений, объединений. В lsfusion все-таки уровень абстрагирования выше, там вы работаете в терминах свойств, классов, ограничений, это более высокоуровневые абстракции. Вы можете вообще ничего не знать про реальную физическую модель в СУБД до поры, до времени (физическую модель в lsfusion можно до определенного уровня легко поменять). То есть в 1С трансляция в SQL - это трансляция с одного языка на язык того же уровня, а в lsfusion - это трансляция с языка более высокого уровня на язык более низкого уровня. В этом отличие.

(864) это справедливо только для языка запросов 1с. Но в 1с есть еще объектная модель, и то, для таблиц регистров накопления справедливым будет "Вы можете вообще ничего не знать про реальную физическую модель в СУБД до поры, до времени". Большинство начинающих 1сников не знают, как построены таблицы регистров накопления. Собственно им это и не нужно.

(857) Нет, примерно с того момента, когда было решено писать статьи, был разговор b про статью про SQL, и про статью про 1C.

(865) Я понимаю, я не говорил, что в 1С нет другого варианта. Я имел ввиду именно варианты, когда пишутся похожие на sql запросы.

(866) а вы заметили, что и в вопросах SQL и вопросах 1с авторам одинаково указывают на некомпетентность их высказываний?

(868) ну я надеюсь вы заметили что в обеих статьях одни из самых заплюсованных комментариев это "шикарная статья" и "я опытный 1с разработчик все так и есть". Ну и первая страница лучших за все время в некоторых хабах как бы намекает.

(868) Мое мнение, что статьи, конечно, не идеально написаны: где-то, возможно, не хватает строгости формулировок и терминологии (к этому легко прицепиться), где-то понятности для стороннего читателя того, что же хотел сказать автор (по мисте это хорошо заметно), а где-то действительно были неточности, которые уже исправили. Но при таком объеме они вряд ли могли получиться идеальными. Да и статьи написаны, на мой взгляд, местами чересчур бескомпромиссно, что вызывает сразу резкую реакцию у некоторых. Но они написаны (а это много труда), и в целом свою роль они выполнили, и реакция того сообщества, на которое они были направлены, c большего положительная, и положительных комментариев там достаточно. Была бы в этих статьях написана совсем ерунда, такого бы количества плюсов не было бы (я знаю, что вы думаете про статью про 1С, что на хабре все против 1С и никто 1С не знает, но тоже самое нельзя сказать про SQL). Да и почитайте сами, например, статью про SQL, там приведено много фактов, которые можно проверить, со ссылками и примерами, зачем кому-то верить.

(864) имхо.
чем выше уровень абстракции и чем их больше - тем тормознее работа.
как-то был пример (в компютерре вроде было) разрабов потокового сканирования и распознавания (когда компы не были столь стремительны  как сейчас, когда вся стремительность сжирается рюшечками и плюшечками). Был написан хороший продукт, с применением ООП и прочего "абстрагирования". Конфетка, а не программа. но. просто не успевало. тупо не успевало. пришлось переписать на простой сермяжный код. и все взлетело.
.
те же самые всякие общие процедуры\функции в 1С во всяких БСП и общих модулях. Сделаны столь универсально и абтрагировано - что превратились в мегапростыни и тонный вызовов по стеку. Потому что - абстракция, епть!

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

(871) Да, чем выше уровень абстракции, тем обычно (но не всегда) больше накладных расходов, с другой стороны обычно это выражается в повышении скорости разработки. Правда, это так вот очевидно работает только внутри какого-нибудь технологического стека или языка программирования. Если мы хотим это притянуть это к тому же сравнению 1C и lsfusion, то это так уже не сработает, ибо различия между платформами очень большие.

(872) А вот тут я совсем не согласен. Обычно все же наоборот, там где выше уровень абстракции, где разработчику нужно работать с более высокоуровневыми понятиями, а не закапываться в низкоуровневых деталях, там и ниже порог вхождения. Понятно, что везде есть исключения, но все же.

(873) нет у вас никаких "высокоуровневых абстракций". Разработчик работает с банальными классами, интерфейсами и т.п. А в 1с высокоуровннвые абстракции есть - справочники, документы, отчеты и иже с ними. Тут даже сравнивать нечего

(854) Хммм... Не подскажете, если идти в сторону от 1С к серверам (что несомненно будет полезно любому 1С), то какие курсы можете порекомендовать? Недавно проходил небольшой курс по MS SQL, но там рассматривалось только в рамках работы с 1С - самые простые вещи, типа тестирования, настройки прав и т.д. через инструменты MS SQL типа Management Studio, монитор, настройка плана обслуживания и т.д. Хотелось бы что-то более предметное, с неким отрывом от 1С. Желательно бесплатное для начала (если есть), но и платное подойдет (всё равно это нужные знания)

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

(867) а вы не задумывались, почему в 1с есть два варианта?

(871) Да, любая проблема дизайна может быть решена внедрением дополнительного виртуального слоя, за исключением проблемы слишком большого количества дополнительных виртуальных слоёв - это про сегодняшний 1С.

Фузина, спаси!!!

(869) а можно ссылку на комментарий "шИкарная статья" под статьей https://habr.com/ru/company/lsfusion/blog/459066/ ? а то я пролистал и не заметил)

(879) Я статьи "Почему не ...?" имел ввиду. Эта статья тут причем? Ее вообще не я писал.

(880) так я и написал о ней и цитаты с нее приводил, как вас повозили мордой по асфальту ораклист. Причем писал он вам тоже что и 1сники)

(870) (880) по поводу статьи по 1с. Вот сейчас серьезно. Есть форумы 1сников. Среди них два самых больших и первых выдаваемых в гугле это инфостарт и миста. Тут тусят 1сники. На хабре еще пару лет назад за положительные отзывы по 1с банили) вы сами в статье своей написали, что люди хаят там 1с, но сами не знают почему)) Сейчас некоторые с инфостарта там пытаются зайти с 1с. Иногда успешно. Но судя по никам в комментах под хаброй, реальных 1сников там банили и минусовали. Положительные отзывы писали ноунеймы, которые никому не известны. Минусование/плюсование на хабре вообще отдельная песня, так как ты не видишь кто тебе ставит плюс, а кто минус. Такое себе узаконенное анонимное стукачество. Поэтому вес этого минуса и плюса равен нулю. Я не знаю кто постаивл этот минус, я не знаю связан он с темой или нет. С таким же успехом вебер придет и напишет статью о динамической типизации и как это круто, зайдут туда джависты и шарпники и заминусуют. Потому что только строгая типизация для них существует, все остальное зло) Объективно это будет? нет. Но вы можете продолжать себя тешить, что плюсы на хабре вашим статьям ставят тру 1сники.

(869) У вас есть статьи на инфостарте? Или вы опять про пикабу? "я опытный одинэснег, всё так как описано" - напоминает экономайзер топлива через прикуриватель - там тоже "я опытный экономизатор, всё так как описано"

(883) Я дочка капитана, тут всё не так однозначно (с)

(864) Вот. Это, на мой взгляд, более корректное значение. Принято.
Просто вопрос, на самом деле, был во влиянии этого на быстродействие. Как-то количеством строк кода мериться, на мой взгляд, довольно странно.

Просто я тут часто видел спор о том, что в фузине что-то делается 3 строками, а в 1с-ке намного большим количеством строк. А тут уже важен баланс. Может быть либо что-то очень длинное и плохо читаемое, либо что-то короткое, но так же плохо читаемое, т.к. при чрезмерном сокращении кода, будет иметь отдельное значение не только каждый оператор, но и разные комбинации этих операторов будут приводить чуть ли не к противоположным результатам, соответственно будет очень много нюансов, пропадет однозначность операторов и т.п.

Либо работа с данными сообще будет некоторым образом размазана.

Я это писал не конктерно в отношении фузины, так как ее не изучал, а вообще.