Ветка для холивара, троллинга, остроумия и оскорблений. Помните, что тонкий троллинг и просто оскорбление - это разные вещи. Переход на личность - признак слабого ума и дурного воспитания.
В красному углу ринга бесплатная и открытая платформа lsFusion (LGPL лицензия). "Убийца 1С" (c) ПростоГен
Сайт : https://lsfusion.org/ . Блог : https://habr.com/ru/company/lsfusion/ . Документация : https://documentation.lsfusion.org/
Пример сложной системы, построенной на ее базе : https://demo.lsfusion.org/erp . Логин : guest, Пароль : guest .

На бой была вызвана статьей "Почему не 1С" : https://habr.com/ru/company/lsfusion/blog/468415/

Демка клона Odoo (в разработке) : https://demo.lsfusion.org/mycompany . Ссылка на GitHub : https://github.com/lsfusion-solutions/mycompany

Предыдущая ветка : OFF: lsFusion vs 1C. Раунд 13

(668) А могли бы сделать на инструменте, который для этого предназначен. Druid + Imply, Tableau, Power BI и многих других BI системах. Было бы и быстрее, дешевле и функциональнее.

(666) и какая из ваших сетей ларьков сумела нагенерить 3 лярда записей? Даже если такая таблица наполнялась 5 лет, в день туда должно залетать 3 млрд / 1825 дн ~ 1,6 млн записей в день. Учитывая, что фузина вылупилась всего полгода назад, скорость наполнения таблицы должна быть ~ 16-17 млн записей в день. У вас там есть свой магнит?

(669) Я очень сомневаюсь, что было бы быстрее, дешевле и функциональнее

(670) Это они чисто теоретически.  Нашли у Driud в рекламе информацию о 3 млрд записей. Фузина умеет работать с Druid, значит умеет работать с 3 млрд записями.

(672) а, ну если так, то ладно

(673)Не работал с Druid. Но есть он умеет 3 млрд записей, а Фузина нет, но может если она будет использовать Druid, то зачем там Фузина?

(674) Не поверите, но и 1С и SAP и Фузина сами не обрабатывают данные. Это делают СУБД. И могут они все одинаково. А Druid, как и другие NoSQL базы устроены не так, как реляционные, и они работают по-другому.

(672) Причем здесь реклама ? У нас на практике есть такие базы :
https://clip2net.com/s/45lJMjX

(676) так что за сеть генерирует такое количество данных?

(676) Вот кстати, скорость работы druid'а :
https://clip2net.com/s/45lJTo0

Сумма по 5 млрд записей. 11.42 секунд. 1С так может ?

(678) Плюс там разное кэширование есть. Вот повторный запрос :
https://clip2net.com/s/45lJVwu

0.35 секунд.

(678) процетирую кое кого: "Не поверите, но и 1С и SAP и Фузина сами не обрабатывают данные. Это делают СУБД" (с)
Если СУБД сможет, то и 1с сможет

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

(680) Но в целом, СУБД, которые заточены под различные запросы в различных срезах (типа Druid), гораздо эффективнее, чем стандартные реляционные СУБД.

(682) да знаем, знаем. Если к фузине докупить яхту, то можно будет и по морю ходить... Может хватит записывать заслуги стороннего ПО в карму фузины?

(677) Это просто datasource, где на каждый день хранятся остатки по каждому товару на каждый день. 600 магазинов каждый день по 12К товаров на остатков в среднем. Вот и будет 5млрд. Datasource нужен, чтобы строить динамику остатков по группам/магазинам, плюс считать товарооборачиваемость по всей сети.

(683) Причем здесь карма фузины. Речь о том, что этот функционал лучше делать в сторонней системе. А 1Совская система отчетности - это недоBI.

(684) а-ха-хах... Н-да, всё ещё запущеннее, чем казалось ранее. И эти люди ругают регистры накопления 1с...

(686) Регистры накопления 1С ругают за то, что они это в реляционной базе делают. Вот, например, запрос с group by по складам на 5 млрд записей :
https://clip2net.com/s/45lKhsN

34 секунды. А на OLTP базе, если это запустить как в 1С, то она подсадит всю базу очень жестко.

(687) И это все на одной небольшой виртуальной машинке. А сила Druid в том, что его можно очень легко масштабировать на любое количество серверов и это все очень круто параллелится. И там такие запросы (и гораздо сложнее, на большем количестве данных) могут за секунду выполнятся.

(688) И да, каждый день с 8млн записей туда загружается с индексацией где-то за 5 минут :
https://clip2net.com/s/45lKuzk

(686) ну вообще это самый эффективный способ получать любые выборки за секунды. А так как OLAP база перобратывать можно как угодно. В том числе денормализуя максимально.

Конкретно в статье вопрос к регистрам накоплений, что в OLTP они избыточны, а в OLAP недостаточны для больших баз / клиентов.

(684) Я смотрю мы о разных миллиардах записей говорим.
Вы "600 магазинов каждый день по 12К товаров на остатков в среднем. Вот и будет 5млрд" для 1С это всего 1 млн записей. Это 2 мин обработки и любой отчет за 1 сек

(689) 8 млн за 5 минут тоже уровень 1С. И опять же это Druid, а не Фузина. меня больше интересует быстродействие Фузины по сравнению с 1С.

(691) Вы хорошо себе представляете, как это хранит 1С, и сколько там записей будет в таблице с остатками ? Чтобы посчитать сумму остатков на каждый день, то это равносильно подсчету интеграла. И это нужно делать либо правилами прямоугольников, либо хранить на каждый день остатки и делать по ним GROUP BY. И в любом случае, какой бы запрос не делался в 1С в среднем к СУБД это будет запрос на чтение 5 млрд записей (если не хранить подитоги по месяцам/годам по всем остаткам). Лучше включите профайлер на сервере БД и покажите планы запросов. Иначе очень похоже на трындежь, или мы говорим о разных вещах. Помню у PR в зарубе на 100К уже 30 секунд работало.

(693) >если не хранить подитоги по месяцам/годам по всем остаткам

Для этого и придуманы регистры накопления в 1С да.

(693) Ладно мы говорим о разных 100 млрд записей.

Есть ли у Фузины что-то типа регистров остатков, оборотов? Или там обычные таблицы?

(694) Вообще мы сейчас про регистры остатков, а не накоплений.

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

Но Фузина этого, я так понимаю, не делает. Т.е. регистрова накопления там нет?

(697) В 1С есть регистры сведений (РС) и регистры накопления (РН), которые можно сделать остатков, оборотов или остатков и оборотов.
Короче херня ваша фузина, там даже РН и РС нету...

Имхо подобная декларативная хрень на ура бы взлетела с NoSQL, но вот с обычной SQL оно как то не того.

(696) что значит обычные таблицы? Регистры в 1с тоже в обычных таблицах хранятся.

Смотрите, регистры в 1с это комбайн из нескольких вещей которые в фузине разделены. Механизм материализаций отдельно (как вычисления остатков, так и их предагрегация). Работа с датами просто условия что дата больше какой то. Вместе с материализациями можно хранить промежуточные итоги, но смысла в этом особого нет, в статье было почему.

Теоретически можно сделать оператор / метакод который будет весь комбайн сразу генерить (то есть по сути передопределенных n свойств). Но благодаря наследованию и тому что например можно группировать с условиями жёсткой потребности в большом числе регистров в lsFusion нет (собственно ни в сап ни в аксапта этого тоже нет). Поэтому пока не добавляли, но может в будущем и добавим такой синтаксический сахар.

Кстати если взять тот же регистр сведений, то это GROUP LAST поэтому тут даже ничего докручивать не надо, так как промежуточные итоги там не сильно актуальны (по сути им является индекс)

(700) Это без проблем может реализовать junior на любой таблице "Хоть на справочниках, хоть на регистрах, хоть на документах"

А что там у нас с транзакциями? Понимает ли Фузина транзакции. Или это опять junior?

(699) Мы же писали, как регистры выглядят в фузине :
https://habr.com/ru/company/lsfusion/blog/465221/

Вы можете сделать любые предагрегации, как хотите. Например, делаете :
sumSold (INTEGER y, Month m) = GROUP SUM sum(SaleLedger l) IF extractYear(date(l)) = y AND extractMonth(date(l)) = m MATERIALIZED;
И все, у вас будет постоянно хранится и обновлятся сумма продаж за год и месяц и можно мгновенно строить отчеты по годам/месяцам. А можно делать MATERIALIZED по любым выражениям.

(702) Это вполне допустимый подход с точки зрения быстродействия.

Т.е. регистры накопления мы делаем сами и на заморачиваемся. Тем более это всего две строчки кода. Только потом на уровне отчетов важно не забыть эти всякие агрегаты. А что с транзакциями?

(697) " Вообще мы сейчас про регистры остатков, а не накоплений."))) чем регистры остатков отличаются от регистров накоплений?) и эти люди пытаются нас убедить что их статья не построенная на лжи

(702) "Теоретически можно сделать оператор / метакод который будет весь комбайн сразу генерить (то есть по сути передопределенных n свойств). Но благодаря наследованию и тому что например можно группировать с условиями жёсткой потребности в большом числе регистров в lsFusion нет" ну собственно в этом и разница между 1с и фузиной. В 1с уже все есть, а в фузине чисто теоретически есть, нужно только подождать когда разрабы платформы добавят две строки) В 1с же мне не нужно ничего ждать, просто кликаешь мышкой и у тебя уже готовый "комбайн" который позволяет вести учет.

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

(710) Речь шла не о том, чтобы увидеть остатки на любую дату, а получить сумму всех остатков на каждую дату.

(707) все обновляется в транзакции (как и в 1с). Кстати можно было бы наверное сделать, чтобы MATERIALIZED автоматически использовался если оптимизатор видит что свойство совпадает с уже материализованным (так sql сервера с матпредставлениями в некоторых случаях делают и считают это крутой фичей). Тогда отчёты автоматически будут их подцеплять. Но опять таки у lsFusion пока не стоит задача заменить аналитические отчёты на больших объемах, там с отказом от ACID и преагрегациями в in memory в специализированных инструментах нет смысла особого тягаться.

(650) Вопрос неверно задан, точнее стоило задать так: "на сколько лет развитие у бро?"

(708) ну краш 1с знает очень поверхностно. Я хотел поправить его, но потом подумал что ник это сам сделает.

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

(708) Этапять!

(709) да. Ну ок допустим у вас есть регистр с измерениями товар и склад. Вам нужно построить регистр по группе товара и складу (скажем просто сумма ресурса для всех активных товаров этой группы). Ваши действия?

(715)я только уточнил вопрос, впрочем извиняюсь

(710) ну так это легко можно посчитать без каких либо предагрегаций кроме текущего остатка. За любой период.

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

(717) с терминами определитесь, я хз что в понятиях фузины активные товары, что в понятии фузинописцев товарная группа(у меня есть предположения по обоим вопросам но что в голове у вас - для меня тёмный лес и будет таковым т.к. от тех кто не понимает необходимости стандартов и методологий можно ожидать любого)

(708) Да, перепутал термины регистры накоплений остатков с регистрами накопления оборотов. Что ж бывает - в 1С же куча дырявых и бесполезных абстракций. В них очень легко запутаться нормальному программисту.

(721) там один регистр - накопления. Остатки и обороты это просто представления на основе этой таблицы регистра (в 1с их ещё называют виртуальными таблицами). Есть ещё даже ОстаткиИОбороты (это и то и другое)

(722) у вас каша в голове, лучше учите матчасть!

(723) ну так расскажите где я неправ просвещенный вы наш :). Хотя даже если так, то это у 1с каша в понятиях раз их так тяжело понять и объяснить.

(723) ну и я в нормальных общепринятых sql терминах пытался объяснить.

(724) РН бываю 2 видов. Бесплатный урок на этом завершается - дальше сами

(725) у sql нет понятий активные товары и товарные группы.

В понятие "документ", "проведение документа"  есть в Фузине?

(726) то что они считают видами это по сути признак материализовать (и давать высчитывать) остатки или нет. То что в описание они их считают "видами" это потому что у них каша в голове. Ну или потому что нормально объяснить этот огород тяжело.

(727) я в качестве примера привел задач, на реплику "есть все" и как иллюстрация почему в lsFusion столько регистров не надо.

(728) нет, по сути это прикладные абстракции для платформы. Но в стандартной lsFusion библиотеке поставляемой вместе с платформой емнип эти классы есть.

А всякие внешние компоненты, COM объекты. Импорт из EXELL. OLE DB. есть?

Фоновые, регламентные задания

(732) да работа с внешними форматами (xml, json, xlax) email'ами, messenger'ами и т.п. Большинство даже на уровне языка.

С com и ole db, есть стандартные функции и механизмы. Но тут надо понимать что это java, то есть в maven прописывается id библиотеки и она автоматически встраивается в проект. А дальше платформа весь java код умеет прозрачно для разработчика пересылать на клиента и выполнять там (опять таки спасибо java), никаких изменений клиента не требуется, все в runtimeе делается.

(734) кроме внешних форматов (csv, dbf ещё и другие), есть интеграция через http и sql интерфейсы в обе стороны тоже прямо на уровне языка. В 99 процентов случаев в современном мире этого достаточно.

(733) да естественно, есть операторы выполнения в новых потоках и встроенный планировщик в том числе с выполнением любых скриптов. Интерпретатор естественно тоже. В общем то есть все или почти все, кроме разве что всяких анкетирование пользователей.

(729) тот кто не знает 1С рассказывает о устройстве структуры данных ИБ... местами спешно, но обычно полная фигня, как сейчас

(730) опять ложь, в оригинале вы писали "в нормальных общепринятых sql терминах". Вы или совсем тупой тролль или у вас полная каша в голове.

(729) в сотый раз призываю, почитай про устройство регистров накопления 1с и как они работают

(739) я уже раз сто читал. Что не так в этом объяснении?

(740)
http://catalog.mista.ru/public/1061227/

(741) Да это основная статья, которую первой выдает гугл. Собственно по ней и был у меня основной вопрос с видом Остатки, а не Обороты. Это в оборотах можно поставить период итогов месяц и тогда считать агрегированные по месяцам. А как в остатках это поможет, если мне нужно сумму остатка на каждый день посчитать ? Если период в Остатках поставить один день, то там и будет 5 миллиардов записей, а SELECT SUM GROUP BY по ним не выполнится за 30 секунд, как в druid'е, а будет часами работать.

Прочитал много букаф и вот решил вставить свои 5 копеек

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

Но не смотря на все "+" на мой взгляд у вас с 2 эпичных "-": это интерфейс и необходимость сторонних систем для формирования
отчетности.

Что касается репортинга - это даже не провал это фаталити. Табличный документ 1с + СКД это сверх мощный инструмент
покрывающий на 200% все потребности бизнеса. Никому не интересны доводы "а вот у них там за бугром стандарт вот такооой..."
Всем на с рать. С какой стороны не посмотри логичнее и эффективнее иметь все в 1м флаконе и логика построения приложений
и сценарии использования в 1с на это заточена целиком и полностью. Никто в здравом уме не откажется от столь удобной
возможности существовавшей в 1с с 90х годов. Если вам всерьез интересна аудитория 1с в качестве потенциальных разрабов -
сделайте и я вас уверяю интерес к сабжу возрастет кратно.

Что касается интерфейса.
Мне понятна ваша логика вы хотели сделать интерфейс максимально декларативный аля как у 1с. Вроде все логично но
скажем прямо это не самая сильная сторона современного 1с. Да УФ - это боль тормоза и кровь из глаз. Но многие научились
его готовить и готовы мириться с "-" в угоду его "+". А то что вы предлагаете это аж на 3 головы хуже 1с и опять же никто
в здравом уме из комьнити 1с не пустит такой интерфейс в прод. За него просто расстреляют на месте. Простите но увы и ах.
Интерфейс откровенно слаб и по функционалу и по дизайну.

В идеале хотелось бы иметь интерфейс аля то что по ссылке  https://webix.com/demos/web-desktop/
Это реально?

Вот сделайте версию lsfusion с адекватным ответом на эти 2 пункта и народ к вам в очередь выстроится. Лично я встану 1м.
В общем и целом появления очередного конкурента 1C всячески привествую. Дайте уже годноту! Дерзайте

(743) + небольшое дополнение
Сразу хочу остудить доводы по п1 что это невозмодно или уних за бугром ток так и никак иначе
Да фот фиг там. Есть библиотеки - а значит и есть потребность. Вот пример

https://www.grapecity.com/spreadjs/designer/content/index.html

Ну что вам мешает это воткнуть в проект?

(717) "Ну ок допустим у вас есть регистр с измерениями товар и склад. Вам нужно построить регистр по группе товара и складу" у меня есть регистр и мне нужно сделать такой же?

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

(721) если нормальный программист не в состоянии запомнить 10 базовых классов, то как он собирается работать в системе с ооп, где классов и объектов десятки?)

(722) ))) зато бро написал статью о 1с. Правда в базовых вещах дупля не отбивает, но статья честная правдивая и компетентная.

(742) читай еще. Нормальный программист, прочитав статью, таких вопросов не задает

(744) "Ну что вам мешает это воткнуть в проект?" руки. Они тут уже прикручивали пивоты и не смогли прикрутить. Все потому что они не могут понять назначение инструмента, что в свою очередь из-за их идеологии - мы делаем то что клиенты хотят. В то время как 1с работает по принципу -даем клиентам то,  что им по настоящему нужно что бы решать их задачи.

(741) и?

Главное отличие этих видов: для регистра накопления с видом "Остатки" ведется учет остатков в разрезе измерений, а также появляется возможность использовать виртуальную таблицу "Остатки".

Ровно то что я и написал.

(743) спасибо за развернутый ответ.

Теперь по порядку.

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

Что касается табличного документа в качестве средства вывода отчётов это очень странная идея, по двум причинам: это слишком громоздко, сильно выбивается из общего интерфейса. Поэтому библиотеки которые мы используем, рендерят все просто через tr td, что делает рендеринг быстрым и его можно сделать визуально похожим на обычный список.

(743) что касается интерфейса. Вопрос к платформе или демкам? Потому как платформа это просто списки, поля, кнопки контейнеры. Сейчас ещё выделили оформление в отдельные css и сделали в частности темные темы. Есть ещё мелочи вроде сворачиваемых контейнеров, избыточных рамок контейнеров, но это лучшее враг хорошего.

Что касается интерфейсов настройки интерфейса пользователем, то это отдельная тема и тут у 1с все ещё хуже (именно касательно эргономики)

(752) А забыл, при этом естественно отчёт в виде tr td (то есть нативной html таблицы) можно выгрузить в excel или другие форматы если надо (но именно если надо)

(752) "Что касается табличного документа в качестве средства вывода отчётов это очень странная идея"
Тем не менее, эта идея оказалась крайне востребованной в отрасли. Это удобно для пользователя, когда результат отчета с сохранением форматирования сохраняется в эксель, где его можно в дальнейшем обрабатывать как хочется здесь и сейчас. Всякие QuickReport и тому подобные ориентированы на "получил-напечатал", ручное редактирование если и допускается, то оно крайне неудобно.

(755) вы не поняли. Интерфейс и в нативной html таблице будет интерактивным. Вопрос именно в пустых лишних ячейках и стилизации под excel.

Строго говоря web excelи нормальные и реализуются через tr td так как это самый быстрый способ рендеринга.

(755) и опять таки она оказалось востребованной именно по сути из за встраиваемой bi из коробки. Табличный документ тут вторичен.

(756) Невозможно html сохранить в excel с сохранением форматирования, слишком разные подходы

(740) всё не так, как тебе представляется

(758) почему? Я же не про любой html, а таблицы в html (то есть теги tr и td). Там именно что матрица как и в Эксель. То есть да не все стили перенесешь в общем случае, но речь то не об этом.

(760) А не вы ли мне говорили, про "отсталость" хтмл-я? что я застрял на 10 лет назад, а тут сами этими языками оперируете?! интересно. И хрен с этими стилями. Главное данные! ЦСС данные передает? - нет. Эксель - поделка для первокурсников. ФАКТ.
"но речь то не об этом." - это тоже факт.

а где фузина? почему нет диалога?

(762) отпуск закончился, парни вышли на работу

(763) я думал трындеть было работой))

Тихо вы, ненароком всплывёт ещё

(762) Не вызывай трупы, они уже вонять начали

(762) 1С ники заняты, пришла пора отчетности, времени на сопли не осталось

(767) Ой, да ладно, сейчас Кружка плеснет говнеца, пару тысяч сообщений за день навалят