Я правильно понял, что вместо отдельного диалогового окна с полноценным поиском и фильтрами вы сделали поиск прямо в поле?
Суть в том, что диалог как раньше можно вызывать просто нажав кнопку сбоку (это видно на гифке). То есть поиск по буквам как бы дополнение, но работает по умолчанию.
Яркий пример - у нас в аналитическом приложении сделан "инфинит-скролл" как в инсте или вк. И плевать что инфинит скролл сделан не для просмотра данных, а для поддержания эффекта "ещё один пост"
У нас везде по умолчанию инфинити-скролл. Да и не только у нас, в 1С тоже так везде. И опять же большинство пользователей считают это значительно удобнее - меньше кликов, и так далее. Например, фактически бесконечный скролл в том же Excel, а люди привыкли именно к нему.
Проблема в том, что там не просто тюнинг. Там иногда надо запросы полностью переписывать для быстрого выполнения (у них оптимизиторы по разному работают). А, учитывая, что типовые сплошь на плоском псевдо-SQL, то очень тяжело сделать, чтобы они одновременно эффективно выполнялись на обоих базах. Поэтому видимо в 1С просто тюнингуют их под MS SQL, а на PostgreSQL — как получится. Понятно, что франчам тогда логичнее не связываться с PostgreSQL.
Так речь и идет о Песочнице. Там в списке установленного ПО есть 1С. Если maven'ом (который там установлен) нельзя затянуть внешние библиотеки, то это очень странное соревнование: «голая» Java + Hibernate + Spring с монолитной платформой, в которую включено уже много чего из коробки.
Там есть такой пункт: Apache Maven + Internal Repository. А что значит Internal Repository? Мог ли я в pom.xml прописать что угодно (в том числе и ссылки на внешние репозитории) и затянуть себе любую библиотеку? Или на Java приходилось довольствоваться только Hibernate + Spring?
Так вот там совершенно другие победители. И никакого 1С там нет. Кроме того, в единственном PDF, который там есть про технологии вообще ничего говорится.
А можете тогда ответить: какие все-таки фреймворки для Java и .Net использовались? И по правилам можно было использовать любой фреймворк для Java и .Net? Или требовалось какое-то согласование?
Однако отметим, что все три участника, использовавшие в качестве инструмента платформу 1С: Предприятие, вошли в первую пятерку — что является безусловным подтверждением мирового уровня технологии 1С: Предприятие.
Очень странно сравнивать платформы для разработки общего назначения (.Net и Java) со domain-specific платформой в задачах из этого домена. Можно было так и с ассемблером соревноваться.
Написали хотя бы, какие фреймворки использовались в Java и .Net.
Вся суть статьи в том, что у платформы 1С много проблем. Давайте не будем скатываться в обсуждение рынка бизнес-приложений и типовых конфигураций. То, что в США на COBOL'е работает куча крупных компаний, автоматически не делает COBOL классной платформой для разработки приложений.
Это статья не про lsFusion, а про 1С. Возможно будет еще и про то, как это сделано в lsFusion. И выше я писал, что если речь идет о производстве на 1С и другой технологии, то эта статья помогает понять, как минимум, что плохо в фундаменте той, что на 1С.
Сравнение сложных IT-систем (в частности, ERP) очень больная тема. Все описанные в статье проблемы имеют прямое отношение к стоимости доработки и сопровождения. Или Вы считаете, что все современные подходы к разработке направлены не на это, а просто на то, чтобы потешить эго разработчиков?
Тут речь не только про lsFusion идет. Если у меня написано на .Net, а у кого-то на 1С, то можно говорить, что там хуже, так как строится на слабой платформе (по крайней мере, с точки зрения маркетинга). Все же понимают, что дом построенный на плохом фундаменте будет хуже, чем тот, который построен на хорошем.
Вообще в эксплуатации всегда включен MATERIALIZED на текущий остаток. Поэтому чтение идет из соответствующей таблицы с остатками по индексу в среднем за миллисекунды.
Если же не хранить текущий остаток, а рассчитывать на основе регистра, то время зависит от очень многих факторов. Как минимум, должен быть индекс ко товару-складу (иначе будет прогон по всей таблице). При наличии индекса расчет будет идти по индексу только на основе записей с этим товаром и складом. Скорость его зависит от того, есть ли нужные страницы в shared buffers СУБД или кэше диска, а также от количества записей. Если в кэше нету, то тогда пойдет обращение к диску и все будет зависеть от скорости диска. Кроме того, может включиться параллелизм, а может не включаться. В общем параметров очень много, но в среднем на 10 млн записей по индексу, если записи в кэше, то будет несколько сот миллисекунд я думаю.
Во-первых, эта статья — просто Tutorial по тому, как в lsFusion реализовывать функционал регистров как в 1С. Сравнение тут не было самоцелью.
Во-вторых, на хабре принято аргументировать и приводить факты, а не просто обвинять в чем-то. Если есть какие-то претензии к статье, то, пожалуйста, укажите пункты, где была дезинформация. Если она подтвердится, то статья будет скорректирована.
Только потрудитесь разобраться в обоих хоть чуть-чуть поглубже, чем только по рекламным статьям с сайта 1С
К сожалению, во всем мире принято полагаться на данные с официального сайта производителя. Цитаты приведены именно с него, и нигде не указано, что это рекламные материалы и не соответствуют действительности.
Я вижу, что Виталик все-таки добрался в отпуске до интернета и одобрил древние комментарии.
1) А можете уточнить, о каком расчете идет речь и в какой таблице должно быть 10 млн. записей? На практике в похожих регистрах в рабочих базах у нас бывает по несколько сот миллионов записей. Естественно, текущий остаток в них помечен как MATERIALIZED и его обновление идет по индексу в таблице с остатками. При этом соответственно неважно сколько всего записей в таблице с регистром, а обновление идет за логарифм от количества записей в таблице с остатками.
2) О какой реструктуризации идет речь? Добавление пустой колонки в PostgreSQL идет в любую таблицу практически мгновенно (такая у них структура хранения данных). Но на практике иногда приходилось добавлять и пересчитывать колонки в таблицы с сотнями миллионов записей. На это могло уходить до часа.
В 1С платная документация? Видимо, чтобы случайно начинающие разработчики не поняли, в какой треш они попадут. А дальше уже как South Park: «ты не сможешь выбросить то, за что уже заплачены деньги».
Суть в том, что диалог как раньше можно вызывать просто нажав кнопку сбоку (это видно на гифке). То есть поиск по буквам как бы дополнение, но работает по умолчанию.
У нас везде по умолчанию инфинити-скролл. Да и не только у нас, в 1С тоже так везде. И опять же большинство пользователей считают это значительно удобнее - меньше кликов, и так далее. Например, фактически бесконечный скролл в том же Excel, а люди привыкли именно к нему.
Там есть такой пункт: Apache Maven + Internal Repository. А что значит Internal Repository? Мог ли я в pom.xml прописать что угодно (в том числе и ссылки на внешние репозитории) и затянуть себе любую библиотеку? Или на Java приходилось довольствоваться только Hibernate + Spring?
Я иду в Skills и там нахожу секцию IT Software Solutions for Business.
Так вот там совершенно другие победители. И никакого 1С там нет. Кроме того, в единственном PDF, который там есть про технологии вообще ничего говорится.
Очень странно сравнивать платформы для разработки общего назначения (.Net и Java) со domain-specific платформой в задачах из этого домена. Можно было так и с ассемблером соревноваться.
Написали хотя бы, какие фреймворки использовались в Java и .Net.
Если же не хранить текущий остаток, а рассчитывать на основе регистра, то время зависит от очень многих факторов. Как минимум, должен быть индекс ко товару-складу (иначе будет прогон по всей таблице). При наличии индекса расчет будет идти по индексу только на основе записей с этим товаром и складом. Скорость его зависит от того, есть ли нужные страницы в shared buffers СУБД или кэше диска, а также от количества записей. Если в кэше нету, то тогда пойдет обращение к диску и все будет зависеть от скорости диска. Кроме того, может включиться параллелизм, а может не включаться. В общем параметров очень много, но в среднем на 10 млн записей по индексу, если записи в кэше, то будет несколько сот миллисекунд я думаю.
Во-вторых, на хабре принято аргументировать и приводить факты, а не просто обвинять в чем-то. Если есть какие-то претензии к статье, то, пожалуйста, укажите пункты, где была дезинформация. Если она подтвердится, то статья будет скорректирована.
К сожалению, во всем мире принято полагаться на данные с официального сайта производителя. Цитаты приведены именно с него, и нигде не указано, что это рекламные материалы и не соответствуют действительности.
1) А можете уточнить, о каком расчете идет речь и в какой таблице должно быть 10 млн. записей? На практике в похожих регистрах в рабочих базах у нас бывает по несколько сот миллионов записей. Естественно, текущий остаток в них помечен как MATERIALIZED и его обновление идет по индексу в таблице с остатками. При этом соответственно неважно сколько всего записей в таблице с регистром, а обновление идет за логарифм от количества записей в таблице с остатками.
2) О какой реструктуризации идет речь? Добавление пустой колонки в PostgreSQL идет в любую таблицу практически мгновенно (такая у них структура хранения данных). Но на практике иногда приходилось добавлять и пересчитывать колонки в таблицы с сотнями миллионов записей. На это могло уходить до часа.