lsFusion 6.0 — открытая и бесплатная платформа для разработки бизнес-приложений

Это абстрактное утверждение или среди организаций, успешно применяющих lsFusion ERP такие есть?

Есть естественно. Представьте сеть гиперов (с их ассортиментом) в разных регионах (с местными товарами). За 10 лет работы.

Собственно на демке MyCompany 20к товаров (к вопросу про пользу кнопки количество записей на любой форме :) ), больше в раз 5-10 чем на любом производстве :)

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

Postgres даже для внешних данных позволяет predicate push down через postgres_fdw, а для внутренних позволяет управлять проталкиванием предикатов с помощью case обертки, но вы отрицаете существование всего этого.

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

Это хорошо, правильно и очень удобно, если обеспечивается платформой (как в lsFusion). Понятно, что если при ошибке разработчика / планировщика база будет ложиться, то это плохо и неправильно, и да придется мучаться с синхронизациями.

Postgres даже для внешних данных позволяет predicate push down через postgres_fdw, а для внутренних позволяет управлять проталкиванием предикатов с помощью case обертки, но вы отрицаете существование всего этого.

Не совсем понимаю причем тут postgres_fdw к вопросу оптимизатора запросов. Что за проталкивание предикатов с case оберткой можете рассказать?

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

https://stackoverflow.com/questions/65489477/postgres-sql-performance-considering-filtering-pagination-inside-vs-outside-subq

Postgres does support predicate pushdown but there are caveats:

• It does not (necessarily) work with CTEs or views.
• It does not (necessarily) work with aggregation queries.
• It does not (necessarily) work with set-based queries, such as union all.

(ну тут правда caveats звучит диковато, так как тут по сути все кроме обычного inline’ого запроса, который не особо то и нужен).

PS: По слухам с 12 версии хотя бы CTE начали инлайнится, но главное же это UNION и aggregation queries.

Что за проталкивание предикатов с case оберткой можете рассказать?

select * from
(
SELECT u.*, 'users' as src FROM users u
union all
SELECT uc.*, 'users_changes' as src FROM users_changes uc
) 
WHERE --applied only to users
      case when src  = 'users' 
                 then city = 'Chicago' --predicate wrapped in case
           else true
      end
  --applied to all
  AND account=12345 

Хотя убей не пойму причем тут CASE, но не суть.

Вы имеете ввиду что он предикат по account сможет внутрь UNION ALL протолкнуть (а точнее развернуть UNION ALL)? Вот честно не уверен, надо пробовать, но вообще основная речь шла про aggregate (GROUP BY, window functions, рекурсивные CTE как более частый и важный случай), и там Postgres точно не проталкивает (так как не может развернуть скажем GROUP BY или window функцию наверх).

Так «не существует» или «их не менее двух»?

Не существует конкретного продукта для сравнения, потому что продуктов много, они разные и у каждого есть свое уточняющее название. Ты же не проводишь сравнение openoffice с программой микрософт. С любой, непонятно какой или со всеми сразу.

Я писал про платформу, а не про решение. lsFusion ERP является приблизительным аналогом 1С: Управление Торговлей 11. lsFusion является аналогом 1С: Предприятие 8.

Ну вот так уже похоже на что-то осмысленное. Осталось только понять, что 1С живет на рынке уже лет 30 примерно, там накоплено много всего и это как хорошо, так и плохо. По правде говоря, не думаю, что когда нибудь появится вменяемая свободная бухгалтерия или управление кадрами, ибо уж больно это зарегулированное и неинтересное дело, отслеживать изменения в законодательстве, формы рисовать, обновления и т.д. А вот ERP, CRM и прочее управленческо-трекерно-мониторинговое почему нет? Да даже онлайн-магазин и склад. Таких систем много, в том числе и готовых к использованию.

Ты же не проводишь сравнение openoffice с программой микрософт. С любой, непонятно какой или со всеми сразу.

Но проводим сравнение Linux с Microsoft.

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

Там сейчас меняется медленней, чем «Интеграционные сервисы» на https://lsfusion-erp.com/modules.html (блин, как можно было сделать веб-систему без возможности дать ссылку на раздел?).

У 1С есть большой плюс в том, что не надо переводить термины предметной области на английский. Заказ покупателя именно ЗаказПокупателя, а не orderShipment. И то, что есть готовая сеть внедренцев-франчайзи.

SELECT income.quantity

СКД такое оптимизирует. Сейчас проверил. Сделал запрос

ВЫБРАТЬ Приход.Количество
	ИЗ Справочник.Номенклатура КАК Номенклатура
	СОЕДИНЕНИЕ
		(ВЫБРАТЬ Товар, СУММА(Количество) КАК Количество
			ИЗ Документ.Отгрузка.Товары КАК  ОтгрузкаТовары
			СОЕДИНЕНИЕ Документ.Отгрузка КАК  Отгрузка ПО ОтгрузкаТовары.Ссылка = Отгрузка.Ссылка
			СГРУППИРОВАТЬ ПО Товар
		) Приход ПО Приход.Товар = Номенклатура.Ссылка

Добавил условие Товар.Категория = 54

Получил запрос к выполнению:

ВЫБРАТЬ
	Приход.Количество КАК Количество
ИЗ
	Справочник.Номенклатура КАК Номенклатура
		ВНУТРЕННЕЕ СОЕДИНЕНИЕ (ВЫБРАТЬ
			ОтгрузкаТовары.Товар КАК Товар,
			СУММА(ОтгрузкаТовары.Количество) КАК Количество
		ИЗ
			Документ.Отгрузка.Товары КАК ОтгрузкаТовары
				ВНУТРЕННЕЕ СОЕДИНЕНИЕ Документ.Отгрузка КАК Отгрузка
				ПО ОтгрузкаТовары.Ссылка = Отгрузка.Ссылка
		ГДЕ
			ОтгрузкаТовары.Товар.Категория = &П
		
		СГРУППИРОВАТЬ ПО
			ОтгрузкаТовары.Товар) КАК Приход
		ПО (Приход.Товар = Номенклатура.Ссылка)

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

И это получается только в СКД, в обычных запросах этого не будет? Интересно в чем прикол делать различные оптимизаторы в разных случаях, это же у разработчика мозг сводить будет. В lsFusion хоть в действиях, хоть на формах хоть где угодно оптимизатор работает всегда и в общем случае.

А в чуть более сложном случае как в примере из ИТС?

Тот пример из ИТС про параметры хранимой процедуры. Особый случай, в общем.

И это получается только в СКД, в обычных запросах этого не будет?

Да. Потому что в обычных запросах отборы известны заранее.

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

Чтобы не было неожиданных эффектов. Запрос разработчика должен работать так, как задумал разработчик. Например, упомянутый в ИТС дополнительный отбор

Номенклатура В (ВЫБРАТЬ Документ.РасходнаяНакладная.Состав.Номенклатура ИЗ Документ.РасходнаяНакладная.Состав ГДЕ Документ.РасходнаяНакладная.Состав.Ссылка = &Документ)

нельзя делать, если в этой накладной, например, больше половины ассортимента.

В lsFusion хоть в действиях, хоть на формах хоть где угодно оптимизатор работает всегда и в общем случае.

Главное, чтобы всегда ускорял, а не замедлял.

Тот пример из ИТС про параметры хранимой процедуры. Особый случай, в общем.

Не совсем понял при чем тут параметр хранимой процедуры. Я имел ввиду, если я сделаю вот такой запрос в СКД, он оптимизируется как они предлагают в ИТС или нет?

ВЫБРАТЬ
    РасходнаяНакладнаяСостав.Номенклатура,
    УчетНоменклатурыОстатки.КоличествоОстаток
ИЗ
    Документ.РасходнаяНакладная.Состав КАК РасходнаяНакладнаяСостав
        ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.УчетНоменклатуры.Остатки КАК УчетНоменклатурыОстатки
        ПО УчетНоменклатурыОстатки.Номенклатура = РасходнаяНакладнаяСостав.Номенклатура
ГДЕ
    РасходнаяНакладнаяСостав.Ссылка = &Документ

Да. Потому что в обычных запросах отборы известны заранее. Чтобы не было неожиданных эффектов. Запрос разработчика должен работать так, как задумал разработчик. Например, упомянутый в ИТС дополнительный отбор

Это очень странно. Потому как все СУБД скажем по умолчанию все сами оптимизируют (и иногда неправильно, для этого хинты есть и то не у всех, скажем у PostgreSQL нет). А там все запросы по определению присылаются разработчиком. А тут же просто обертка (транспиллер) над SQL и ответственность на разработчика перекладывают.

нельзя делать, если в этой накладной, например, больше половины ассортимента.

Ну так оптимизатор это и должен учитывать из статистики. Понятно, что можно ошибиться, но lsFusion в этом плане хитро делает, оценивает прогнозируемое время выполнения, и если ошибается, fallback’ает к более пессимистичному плану.

При том, что РегистрНакопления.УчетНоменклатуры.Остатки это не таблица. Это типа ЛЕВОЕ СОЕДИНЕНИЕ sp_totals(РегистрНакопления.УчетНоменклатуры, ТекущаяДата(), ).

РасходнаяНакладнаяСостав.Ссылка = &Документ

Это не оптимизируется, потому что если считать, что УчетНоменклатурыОстатки таблица, то дополнительный отбор излишен. А в хранимую процедуру можно пробросить только отборы по измерениям, к которым РасходнаяНакладнаяСостав.Ссылка не относится.

Если бы был отбор по номенклатуре, он бы применился и к РасходнаяНакладнаяСостав и к параметру хранимой процедуры.

А тут же просто обертка (транспиллер) над SQL и ответственность на разработчика перекладывают.

Потому что эта обёртка должна предсказуемо транслироваться в SQL, а не внезапно тормозить от того, что транслятор не туда отбор добавил.

Понятно, что можно ошибиться, но lsFusion в этом плане хитро делает, оценивает прогнозируемое время выполнения, и если ошибается, fallback’ает к более пессимистичному плану.

Если этот механизм надёжен, то непонятно, почему этот механизм надо делать на уровне lsFusion, а не на уровне PostgreSQL. Вроде как оба продукта открыты, что мешает перенести?

Если этот механизм надёжен, то непонятно, почему этот механизм надо делать на уровне lsFusion, а не на уровне PostgreSQL. Вроде как оба продукта открыты, что мешает перенести?

Потому что lsFusion по определению работает в 3НФ (то есть с функциями по сути), а не с голой реляционной алгеброй. Ну и использует еще кое какую специфику, которую линейно не перенесешь в PostgreSQL. Не говоря уже о том, что lsFusion написан на Java очень активно использует ООП (наследование и полиморфизм) + сборщик мусора внутри, а PostgreSQL ЕМНИП написан на чистом C с ручным управлением памятью.

Хотя в целом не спорю, лучше бы конечно, чтобы все эти оптимизации (начиная от Join Predicate Push Down) делались бы внутри PostgreSQL, но похоже им это не под силу :(

Потому что эта обёртка должна предсказуемо транслироваться в SQL, а не внезапно тормозить от того, что транслятор не туда отбор добавил.

Ну это философский вопрос, попахивающий луддизмом. И практически все СУБД с этим тезисом не согласны, в плане что сами переписывают SQL запрос как хотят.

Это не оптимизируется, потому что если считать, что УчетНоменклатурыОстатки таблица, то дополнительный отбор излишен. А в хранимую процедуру можно пробросить только отборы по измерениям, к которым РасходнаяНакладнаяСостав.Ссылка не относится.

Если честно не совсем понял. Остатки это не таблица это подзапрос (представление, но по сути подзапрос). И туда тоже неплохо проталкивать предикат, что в ИТС почему-то предлагают делать руками, хотя тот же lsFusion это спокойно это при необходимости делает автоматически.

Ну это философский вопрос, попахивающий луддизмом. И практически все СУБД с этим тезисом не согласны, в плане что сами переписывают SQL запрос как хотят.

Вот СУБД может переписывать, так как знает внутреннюю структуру и статистику базы, а для обёртки над СУБД это нежелательно. Особенно для переносимой обёртки.

Остатки это не таблица это подзапрос (представление, но по сути подзапрос)

Ты считаешь, что надо делать что-то вроде

ВЫБРАТЬ
    РасходнаяНакладнаяСостав.Номенклатура,
    УчетНоменклатурыОстатки.КоличествоОстаток
ИЗ
    Документ.РасходнаяНакладная.Состав КАК РасходнаяНакладнаяСостав
        ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.УчетНоменклатуры.Остатки КАК УчетНоменклатурыОстатки
        ПО УчетНоменклатурыОстатки.Номенклатура = РасходнаяНакладнаяСостав.Номенклатура И Номенклатура В (ВЫБРАТЬ Номенклатура ИЗ Документ.РасходнаяНакладная.Состав ГДЕ РасходнаяНакладнаяСостав.Ссылка = &Документ)
ГДЕ
    РасходнаяНакладнаяСостав.Ссылка = &Документ

? Уверен, что так быстрее?

И туда тоже неплохо проталкивать предикат, что в ИТС почему-то предлагают делать руками

В ИТС его не в подзапрос пихают, а в параметр функции.

Кстати, интересно, можно ли в lsFusion сделать аналог остатков 1С?

Должно быть что-то вроде

Функция Остатки(Таблица, Дата, Условие, Измерения, Ресурсы)
  Если ПустаяДата(Дата) Тогда
    Возврат Сгруппировать(Измерения, Ресурсы, "ВЫБРАТЬ * ИЗ " + ТаблицаАктуальныхОстатков(Таблица) + " ГДЕ " + Условие");
  Иначе
    Возврат Сгруппировать(Измерения, Ресурсы,
       "ВЫБРАТЬ * ИЗ " + ТаблицаИтогов(Таблица) + " ГДЕ " + Условие + " И Период = " + НачалоМесяца(Дата) 
       + " ОБЪЕДИНИТЬ ВСЕ ВЫБРАТЬ * ИЗ " + Таблица + " ГДЕ " + Условие + " И Период МЕЖДУ " + НачалоМесяца(Дата) + " И " + Дата);
  КонецЕсли;
КонецФункции

Что-то мне не везёт с тестированием lsFusion.

Зашёл на https://demo.lsfusion.org/mycompany-ru/
Выбрал сверху Склад, слева Себестоимость остатков.
Вверху слева есть поле «Выбрать дату», но при попытке по нему щёлкнуть или что-то туда ввести полсекунды в этом поле крутится колёсико и оно остаётся пустым.