Выбор, что хотите, ставите пессимистичную блокировку (я писал выше как), хотите нет. Что вам конкретно непонятно? Если действительно непонятно, ответьте на вопрос:
Как например должно по вашему определяться где в 1С должны ставиться управляемые блокировки, а где нет.
Вы же в курсе что версионный режим СУБД МЕНЕЕ целостный (то есть вот эта ваша ошибка на миллион), но гораздо более масштабируемый. И все равно абсолютное большинство сложных нагруженных систем используют именно версионные СУБД. Потому что баланс рисков / возможностей. Или вы не согласны с формулой:
Еще раз в бизнесе это всегда про соотношение: Затраты на решение проблемы + затраты на преодоление ограничений от ее решений (например менее эффективную работу сотрудников) vs вероятность возникновения проблему * ущерб ее устранения.
Весь тот код, что есть в первой статье только для проверки одного ограничения. Вы думаете я с кодом не умею работать? Если так то откройте исходники УТ и покажите, где он еще используется. Может я действительно что-то пропустил.
Так это вы накручиваете. Мне если честно не доставляет столько удовольствия, объяснять одни и те же вещи по 100 раз.
Что значит почему? Потому как если в данной области распространен этот поставщик, то под него и подстраиваться. Если основной движок интернет магазинов условная Joomla, то все будут подстраиваться под него, если у есть всего один сервис Честный знак все будут подстраиваться под него, если 90% касс это Сервис-плюс и Кристаллсервис, все будут подстраиваться под них, если 90 процентов бухгалтерий 1С: Бухгалтерия, все будут подстраиваться под нее и так далее. Так всегда и везде работает.
Дадада, всё у вас удалось. Ни у кого в мире не удавалось, но у вас конечно всё есть.
А я объясню, потому что реализовать одну такую фишку не возможно. Нужно реализовывать весь lsFusion целиком в том виде что есть сейчас. А это очень сложная архитектурно не масштабируемая деньгами задача.
как вы будете определять, в какой ситуации нужна пессимистичная блокировка, а где оптимистичная?
А как вы определяете где нужна в 1С управляемая блокировка, а где нет? Даю подсказку, аналитически или по факту инцидента.
И вы упорно игнорируете факт про победу версионников над блокировочниками (скажем у Oracle и Postgres так и не появился блокировочный режим, а у MS SQL появился версионный и его даже 1С частично начал использовать), победу git над блокировочными системами контроля версий, победу google docs над расшаренным excel / word и т.п. Может прокомментируете? Или там типа ошибок на миллион нет (хотя везде есть / могут быть).
Ту ситуацию ни в одной системе нельзя обойти, только организационно.
Так, а смысл бороться с ситуацией, если вы в 95 процентов случае все равно получите проблему. Это как если бы вероятность смерти от рака уменьшалась бы на 5 процентов, если вы не будете пить, ложится спать в 9, не есть ничего вредного и т.п. Знаете что большинство пользователей сказало бы? Ну его нафиг. То есть опять-таки баланс рисков / возможностей.
Как ваша программа будет определять, когда нужно включать «защиту», а когда не надо?
Так это администратор по большому счету должен решать, ну и разработчик (естественно максимально декларативно).
Как например должно по вашему определяться где в 1С должны ставиться управляемые блокировки, а где нет. То то же.
Ваша аналогия некорректна. IT — достаточно уникальная среда, чтобы не сравнивать ее с простыми «житейскими» ситуациями.
Точно, законы логики, оптимизации и вероятностей там не работает.
Если пользователь может совершить ошибку — однажды он ее совершит. Задача разработчика ПО — как можно сильнее заблокировать пользователю возможности «совершить ошибку».
Ну тогда можно просто сделать базу однопоточной и все будет ок. Ну или просто заблокировать пользователю все возможности. Еще раз это всегда вопрос баланса возможностей и рисков. Just business.
Ну и в сто первый раз, lsFusion дает выбор (!), а 1С нет. А сейчас все эти споры мне до боли начинают напоминать классическое «все беды от мяса».
Тогда бы все СУБД были блокировочниками. И вообще все бизнес-приложения однопоточными.
Еще раз в бизнесе это всегда про соотношение: Затраты на решение проблемы + затраты на преодоление ограничений от ее решений (например менее эффективную работу сотрудников) vs вероятность возникновения проблему * ущерб ее устранения.
Может. Если платформа сама сгенерит такой инкрементальный запрос. Кстати, строго говоря, с материализованными представлениями тот же Oracle ЕМНИП например так и делает.
Причем тут пользователи? У пользователей как раз все зашибись они работают параллельно, система сама следит за целостностью (гарантируя ее). Те же ситуации когда кто-то кого то затер с тем же пересчетом надуманные, так как пересчет с гораздо (!) большей вероятностью пройдет через 5 секунд после изменения первого пользователя и будут те же яйца.
Еще раз у нас десятки достаточно крупных клиентов (многие из которых по российским меркам вошли бы в топ 20 розничных сетей) именно с огромным числом пользователей и большими документами (причем выносят нам мозг по каждой мелочи) и ни один я не припомню чтобы озвучил нам эту проблему (потому как иначе мы бы им давно включили пессимистичные блокировки). Наоборот счастливы как слоны, что инвентаризацию могут вдесятером менять.
Ну формально в Odoo есть надстройка на питон, какой то частный случай материализаций. Но у них да, платформа очень сильно слита с решением и поэтому тяжело с ними сравнивать.
Первый вопрос, раз статья на хабра, значит желаете привлечь в первую очередь ИТ специалистов. Дайте ссылку на туториал, как развернуть систему и написать простейшую учетную систему, например «Домашняя бухгалтерия». Посмотрите по аналогии с 1С «Радченко. Практическое пособие разработчика.», ознакомление с платформой в таком ключе было бы максимально понятным.
Вот это страшно! 1С когда-то вместо «пользователь Excel» использовала слово «бухгалтер».
Это наследие до сих пор не дает спокойно спать по ночам многим 1Сникам.
Ну так 1С всегда был чистой императивщиной. Они пытались ее замаскировать визуальным программированием, но это тоже самое в другой обертке.
Далее, вы упираете только на бесплатность, простоту разработки(и то пока под вопросом), и скорость? Или еще что-то есть?
Чтобы, например, презентовать систему руководству компании должно быть что-то еще.
Еще модульность (это один из важных кейсов, причем как вертикальная, так и горизонтальная, то есть поставляются только те модули что нужно, а не зайдите в пятую вкладку, тут не смотрите там не жмите, это на всякий случай заполните, а то не пропустит), технологичность (веб, все дела), производительность (у нас огромные сети с постоянно дорабатываемой логикой тысячами одновременных пользователей, на весьма дешевом железе работают, причем даже во многих случаях без кластеризации), целостность (если есть ограничение оно железобетонное, а не как в остальных системах, дай проведу неоперативно просто), эргономичность (например тот же параллельный ввод, который тут уже полветки обсуждаем) и т.п.
Но на самом деле основное все же скорость / простота разработки, так как это по факту дает три вещи:
1. Бизнес начинает управляться через ИТ-систему (по факту процессы внедряются именно в ИТ-систему, создавая декларативные ограничения, которые пользователи не могут обойти и по факту им приходится работать как надо, «организационное» управление становится вторичным)
2. ИТ-система подстраивается под бизнес, а не наоборот (что позволяет реализовывать именно свои know how, а не универсальный бест-практис, который подходит только какому-то среднему бизнесу и по сути нивелирует конкретно твои конкурентные преимущества)
3. ИТ-система внедряется постепенно бесшовно без риска для бизнеса, сначала as is (причем с полной интеграцией по мастерданным, часто в обе стороны) потом постепенно мигрируя в to be.
И вот эти вещи на самом деле мы как правило продаем.
А вообще тут на первой странице собрано про платформу (про продуктам отдельные сайты есть / делаются и там вот это все сверху есть / будет): ru.lsfusion.org
Наоборот как раз. Части проблем этой / предыдущей статьи в 7.7 нет (например из-за ОФ, автоматических блокировок и т.п.).
но и универсальность и гибкость
Ага только скорость / стоимость разработки, надежность, поддерживаемость решений в последних версиях оставляет мягко говоря желать лучшего (я сейчас не про примитивный CRUD, а когда на руках уже сложная система аля УТ, или даже хотя бы УНФ). Собственно в этой статье и заключении я насчитал только под 30 пунктов.
Да и 99% рынка в РФ никто не отменял
Ну прям таки 99%. Даже в БУХ и ЗУП хорошо если 90%. А скажем в управленческих решениях крупного ритейла или банках того же 1Са очень мало. Ну или если горизонтально смотреть, в WMS они не лидер, в CRM тоже нет, в электронном документообороте тоже мимо, ну и т.п.
Ну строго говоря если взять статьи по количеству просмотров и комментов, статей где идет акцент на 1С хорошо если 20%. Ну и с другой стороны это логично, это все же самый распространенный инструмент на постсоветском пространстве.
Ну как говорится «все познается в сравнении». Собственно когда человек выбирает любой инструмент (не только в ИТ), он как правило читает про недостатки одних инструментов и преимущества других (собственно недостатки и преимущества всегда являются зеркальным отражениям друг друга).
А в вашей системе, выходит, агрегирование для контроля остатка производится безусловно, даже если этого можно и не делать? А строк, знаете ли, могут быть миллионы…
Нет, в этом и фокус. Всю эту тонну кода, который в 1С разработчик делает руками, lsFusion делает АВТОМАТИЧЕСКИ. Она сама определяет какие данные изменились, сама записывает во временные таблицы, сама строит инкрементальные запросы и т.п.
Моя многолетняя практика 1С показывает, что если ERP-система выходит из рамок локальной сети в интернет, то разделение контекстов на клиент и сервер уже не является пустым звуком. Взять хотя бы загрузку данных в условный отчет комиссионера из того же экселя. Он может весить туеву хучу. Зачем гонять его на сервер? Вполне достаточно разобрать его полностью на клиенте и отправить минимальный объем данных на сервер, ну и так далее, боевые примеры могу приводить бесконечно.
Можно, только в 95 процентов нафиг не нужно (да и в вашем случае сомнительно). Ну сэкономите вы 10% на оборудовании (и то не факт), зато очень сильно увеличите стоимость доработок (так как код будет куда более сложным / непонятным), уменьшите надежность (так как при большем количестве кода куда больше ошибок и т.п.). Классическая premature оптимизация. Опять таки многолетний опыт на очень сложных системах крупной розницы с очень большим объемом данных / пользователей.
Это чей-то мозговой клин. Программисты самой 1С — тоже люди. Можете смело удалить это условие из параметров виртуальной таблицы — план запроса не изменится.
Что значит мозговой клин? Это офдокументация. И что значит не изменится план запроса? Запрос к SQL базе не изменится или план не изменится? Потому как в postgres или файловой очень даже изменится (почитайте этот раздел). Да и в MS SQL, если сгенерится какой нибудь COALESCE (например FULL JOIN), план запроса тоже очень даже изменится. Собственно поэтому в типовых эти предикаты и проталкивают руками.
Для того чтобы это все нормально работало под postgres и даже MS SQL, нужен нормальный аля-CBO оптимизатор запросов сверху, а для этого нужна статистика и много чего еще, а 1С даже более простые вещи не реализовал.
Прекратите везде пихать «правило Парето», как универсальный аргумент. Вы не понимаете границ его использования, так еще и лихо меняете
Это вы не понимаете его суть. То что в 80 (или 95) процентов может делаться просто должно делаться просто. В остальных случаях должна быть ВОЗМОЖНОСТЬ сделать сложно. Заставлять делать лишнюю работу разработчика это в лучшем случае premature оптимизация и одно из самых больших зол в разработке.
Закон Мерфи — это вообще говоря сатирический (несерьезный) закон. Причем тут он не понятно. И крутятся миллионы это демагогический прием, если вы посчитаете затраты на борьбу с проблемой и сравните с вероятностью проблемы умноженной на ущерб все будет совсем не так как вы видите.
Когда ваш эфемерный «1%» будет стоить вам миллионы
Когда будет стоить миллионы, тогда и включите пессимистичную блокировку (ну или лучше ограничениями поработаете). Пример про гололед я уже приводил выше. Ну и про борьбу оптимистичных блокировок с пессимистичными (кстати борьба SQL-серверов версионников с блокировочниками ну вот прямо один-в-один то что вы говорите, напомнить кто там выиграл).
И все само встанет на свои места.
Вы же в курсе что версионный режим СУБД МЕНЕЕ целостный (то есть вот эта ваша ошибка на миллион), но гораздо более масштабируемый. И все равно абсолютное большинство сложных нагруженных систем используют именно версионные СУБД. Потому что баланс рисков / возможностей. Или вы не согласны с формулой:
Так это вы накручиваете. Мне если честно не доставляет столько удовольствия, объяснять одни и те же вещи по 100 раз.
А я объясню, потому что реализовать одну такую фишку не возможно. Нужно реализовывать весь lsFusion целиком в том виде что есть сейчас. А это очень сложная архитектурно не масштабируемая деньгами задача.
А как вы определяете где нужна в 1С управляемая блокировка, а где нет? Даю подсказку, аналитически или по факту инцидента.
И вы упорно игнорируете факт про победу версионников над блокировочниками (скажем у Oracle и Postgres так и не появился блокировочный режим, а у MS SQL появился версионный и его даже 1С частично начал использовать), победу git над блокировочными системами контроля версий, победу google docs над расшаренным excel / word и т.п. Может прокомментируете? Или там типа ошибок на миллион нет (хотя везде есть / могут быть).
Так, а смысл бороться с ситуацией, если вы в 95 процентов случае все равно получите проблему. Это как если бы вероятность смерти от рака уменьшалась бы на 5 процентов, если вы не будете пить, ложится спать в 9, не есть ничего вредного и т.п. Знаете что большинство пользователей сказало бы? Ну его нафиг. То есть опять-таки баланс рисков / возможностей.
Так это администратор по большому счету должен решать, ну и разработчик (естественно максимально декларативно).
Как например должно по вашему определяться где в 1С должны ставиться управляемые блокировки, а где нет. То то же.
Точно, законы логики, оптимизации и вероятностей там не работает.
Ну тогда можно просто сделать базу однопоточной и все будет ок. Ну или просто заблокировать пользователю все возможности. Еще раз это всегда вопрос баланса возможностей и рисков. Just business.
Ну и в сто первый раз, lsFusion дает выбор (!), а 1С нет. А сейчас все эти споры мне до боли начинают напоминать классическое «все беды от мяса».
Еще раз в бизнесе это всегда про соотношение: Затраты на решение проблемы + затраты на преодоление ограничений от ее решений (например менее эффективную работу сотрудников) vs вероятность возникновения проблему * ущерб ее устранения.
Еще раз у нас десятки достаточно крупных клиентов (многие из которых по российским меркам вошли бы в топ 20 розничных сетей) именно с огромным числом пользователей и большими документами (причем выносят нам мозг по каждой мелочи) и ни один я не припомню чтобы озвучил нам эту проблему (потому как иначе мы бы им давно включили пессимистичные блокировки). Наоборот счастливы как слоны, что инвентаризацию могут вдесятером менять.
ru-documentation.lsfusion.org/pages/viewpage.action?pageId=2228236
ru.lsfusion.org/try
Хотя согласен есть над чем работать.
Ну так 1С всегда был чистой императивщиной. Они пытались ее замаскировать визуальным программированием, но это тоже самое в другой обертке.
Еще модульность (это один из важных кейсов, причем как вертикальная, так и горизонтальная, то есть поставляются только те модули что нужно, а не зайдите в пятую вкладку, тут не смотрите там не жмите, это на всякий случай заполните, а то не пропустит), технологичность (веб, все дела), производительность (у нас огромные сети с постоянно дорабатываемой логикой тысячами одновременных пользователей, на весьма дешевом железе работают, причем даже во многих случаях без кластеризации), целостность (если есть ограничение оно железобетонное, а не как в остальных системах, дай проведу неоперативно просто), эргономичность (например тот же параллельный ввод, который тут уже полветки обсуждаем) и т.п.
Но на самом деле основное все же скорость / простота разработки, так как это по факту дает три вещи:
1. Бизнес начинает управляться через ИТ-систему (по факту процессы внедряются именно в ИТ-систему, создавая декларативные ограничения, которые пользователи не могут обойти и по факту им приходится работать как надо, «организационное» управление становится вторичным)
2. ИТ-система подстраивается под бизнес, а не наоборот (что позволяет реализовывать именно свои know how, а не универсальный бест-практис, который подходит только какому-то среднему бизнесу и по сути нивелирует конкретно твои конкурентные преимущества)
3. ИТ-система внедряется постепенно бесшовно без риска для бизнеса, сначала as is (причем с полной интеграцией по мастерданным, часто в обе стороны) потом постепенно мигрируя в to be.
И вот эти вещи на самом деле мы как правило продаем.
А вообще тут на первой странице собрано про платформу (про продуктам отдельные сайты есть / делаются и там вот это все сверху есть / будет):
ru.lsfusion.org
Ага только скорость / стоимость разработки, надежность, поддерживаемость решений в последних версиях оставляет мягко говоря желать лучшего (я сейчас не про примитивный CRUD, а когда на руках уже сложная система аля УТ, или даже хотя бы УНФ). Собственно в этой статье и заключении я насчитал только под 30 пунктов.
Ну прям таки 99%. Даже в БУХ и ЗУП хорошо если 90%. А скажем в управленческих решениях крупного ритейла или банках того же 1Са очень мало. Ну или если горизонтально смотреть, в WMS они не лидер, в CRM тоже нет, в электронном документообороте тоже мимо, ну и т.п.
Нет, в этом и фокус. Всю эту тонну кода, который в 1С разработчик делает руками, lsFusion делает АВТОМАТИЧЕСКИ. Она сама определяет какие данные изменились, сама записывает во временные таблицы, сама строит инкрементальные запросы и т.п.
Можно, только в 95 процентов нафиг не нужно (да и в вашем случае сомнительно). Ну сэкономите вы 10% на оборудовании (и то не факт), зато очень сильно увеличите стоимость доработок (так как код будет куда более сложным / непонятным), уменьшите надежность (так как при большем количестве кода куда больше ошибок и т.п.). Классическая premature оптимизация. Опять таки многолетний опыт на очень сложных системах крупной розницы с очень большим объемом данных / пользователей.
Что значит мозговой клин? Это офдокументация. И что значит не изменится план запроса? Запрос к SQL базе не изменится или план не изменится? Потому как в postgres или файловой очень даже изменится (почитайте этот раздел). Да и в MS SQL, если сгенерится какой нибудь COALESCE (например FULL JOIN), план запроса тоже очень даже изменится. Собственно поэтому в типовых эти предикаты и проталкивают руками.
Для того чтобы это все нормально работало под postgres и даже MS SQL, нужен нормальный аля-CBO оптимизатор запросов сверху, а для этого нужна статистика и много чего еще, а 1С даже более простые вещи не реализовал.
Это вы не понимаете его суть. То что в 80 (или 95) процентов может делаться просто должно делаться просто. В остальных случаях должна быть ВОЗМОЖНОСТЬ сделать сложно. Заставлять делать лишнюю работу разработчика это в лучшем случае premature оптимизация и одно из самых больших зол в разработке.
Закон Мерфи — это вообще говоря сатирический (несерьезный) закон. Причем тут он не понятно. И крутятся миллионы это демагогический прием, если вы посчитаете затраты на борьбу с проблемой и сравните с вероятностью проблемы умноженной на ущерб все будет совсем не так как вы видите.
То что весь этот код нужен ТОЛЬКО для проверки ОДНОГО ограничения, а в lsFusion для этого одна декларативная строка кода.
Когда будет стоить миллионы, тогда и включите пессимистичную блокировку (ну или лучше ограничениями поработаете). Пример про гололед я уже приводил выше. Ну и про борьбу оптимистичных блокировок с пессимистичными (кстати борьба SQL-серверов версионников с блокировочниками ну вот прямо один-в-один то что вы говорите, напомнить кто там выиграл).