• Не очередной язык программирования. Часть 1: Логика предметной области
    0
    Пользователи работают с одной записью, скажем товар или какой то ряд из справочника. Оба они меняют одно и то же поле, например, Имя. Пусть начальное значение имени «Соль». Первый пользователь меняет имя на «Сахар», все хорошо, он видел верное предыдущее значение «Соль» и заменил его новым осознанно. Второй же пользователь видел устаревшее значение «Соль» и переписал его на «Хлеб», при этом результат работы первого пользователя он пропустил, то есть он даже не узнал, что отменил работу первого пользователя.

    Я тоже понимаю о чем вы говорите :). И вы же я надеюсь тоже понимаете, что описанная вами ситуация надуманная. По идее оба пользователя будут менять название на Сахар. Ну или один из них вредитель, но он поменяет название на Хлеб в любом случае. То есть если пользователь считает что этот товар Сахар, ему все равно как он назывался до (Соль или Хлеб).

    Вообще ORM делают эти проверки не для таких случаев, а чтобы соседние изменения не затирались.

    В принципе можно и в lsFusion такой механизм реализовать, но там другой нюанс возникает. В lsFusion все списки динамические, то есть тот же документ читается не целиком, а как и остальные данные по частям (то есть только видимая часть). Это позволяет открывать большие документы мгновенно плюс значительно уменьшать нагрузку на сервера (как memory footprint так и нагрузку по сети), собственно то для чего и нужны динамические списки. И соответственно возникает вопрос на какой момент считать данные актуальными. По сути это надо делать на момент скроллинга, что немного не интуитивно понятно. Ну и в любом случае все это дело это значительный оверхед, а выигрыш не понятен (во всяком случае у нас больше полусотни крупных проектов из различных областей с суммарно >10к пользователей, и нам выносят мозг по любой мелочи, но с такими проблемами никто не обращался).
    Например, в какой-то список могут быть дважды добалены элементы с одинаковым именем, хотя бизнес логика может быть к такому не готова.

    А вот это из другой оперы. Тут как раз вы делаете:
    xById = GROUP AGGR x BY id(x) MATERIALIZED;
    И update conflict'ы вам не дадут создать два элемента с одинаковым id ни в каком случае. То есть один из пользователей сохранит изменения, второй получит update conflict на записи xById, а при повторном проведении выдастся constraint (который неявно создается в GROUP AGGR) что уникальность нарушена.
  • Не очередной язык программирования. Часть 1: Логика предметной области
    0
    возникает ситуация когда чужие изменения могут быть затерты непреднамерено.

    Вы немного путаете. Непреднамеренно они затерты быть не могут, потому как lsFusion не объектно-ориентирован и не загружает объект целиком в память как тот же 1С. То есть если даже один пользователь поменял одно поле в одной строке, а другой пользователь поменял другое поле в этой же строке, то изменения обоих благополучно запишутся. А именно это проблема классического ORM, когда два пользователя открыли документ, один изменил в одной строке, другой в другой, и изменения одного пропали. И именно для этого нужны все эти предупреждения. Если же два пользователя меняют одно и то же значение, то смысла в описанных вами проверках мало, так как пользователю как правило все равно с (!) какого значения он меняет, если он хочет 5 он введет 5, и как правило ему все равно до было 3 или 1.

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

    На самом деле в таком случае процесс уходит в «бесконечный» update conflict (например до вечера, когда нагрузка спадет, ну или ему сильно повезет днем). Но что важно, что при этом он оперативной работе базы практически не мешает (в этом сила версионников и почему они «победили» блокировочники).

    Соответственно, на практике просто рубят транзакцию на блоки, и делают промежуточные APPLY (понятно что при этом надо учитывать, что целостность операции может уменьшаться).
  • Не очередной язык программирования. Часть 1: Логика предметной области
    0
    del
  • На пути к функциональной СУБД и NoSQL ERP: хранение остатков и расчет себестоимости
    0
    Функциональная функция (простите за тафталогизм) всегда возврщает новые данные, поэтому ФП так критикуем и непопулярен, ведь аллокации памяти это дорого.

    С чего вы взяли? ФП вообще перпендикулярен работе с памятью (то есть можно по разному делать). И как раз в ФП экономить память (и ее аллокацию) куда проще чем в императивном: а) из-за ленивых вычислений, б) потому что вы можете переиспользовать ссылки на объекты не боясь что их кто-то изменит (если у вас вся архитектура на immutable объектах / чистых функциях, соответственно immutable объекты создаются только в императивной части — процедурах). И кстати поэтому ФП очень популярен именно в системном программировании, потому как на сложных архитектурах при использовании ФП с многопоточностью и памятью (кэшированием) все становится значительно проще.
    Именно! Вы совершенно верно схватили суть! На такую схему навернуть блокчейн — пять минут программирования, просто вычислить хэш и положить в дерево Меркла. А вот если у нас есть мутабельный регистр «Остатки», то как его надежно защитить от подделок и ошибок? Никак.

    Ну насколько хорош или плох блокчейн это отдельная тема. И находится она в основном в политическо/экономической плоскости, так что к данной статье имеет мало отношения :)
  • На пути к функциональной СУБД и NoSQL ERP: хранение остатков и расчет себестоимости
    +1
    Нет, скорее «перепроведение документов» про это самое. Пересчет регистров это все же немного из другой оперы (хотя наверное какая-то корреляция все же есть)
  • На пути к функциональной СУБД и NoSQL ERP: хранение остатков и расчет себестоимости
    0
    Если честно, для меня рассматривать остаток как сущность (класс, объект и т.п.) это очень странная концепция. На мой взгляд остаток это чистая функция.
    Любая функция (даже чистая) возвращает какие-то данные, в моем случае — новый документ типа «баланс».

    Вообще чистая функция (а ФП это именно про чистые функции, потому как не чистые функции это просто процедуры, которые умеют записывать результат в переменные) никак не может возвращать новый документ. Потому как при повторном вызове она получается вернет другой документ, что противоречит ее чистоте. Это никак не ФП.
    Чувствуете разницу?

    Нет, разница чисто в особенностях реализации. По сути вы просто создаете транзакционный лог. Я бы на вашем месте это скорее блокчейн СУБД, а не функциональной СУБД называл бы. Ведь именно блокчейн это про аудируемость и т.п.
  • Не очередной язык программирования. Часть 1: Логика предметной области
    0
    Родными средствами СУБД. Уровень изоляции повышается до Repeatable Read (можно и Serializable в Postgres, но там масштабируемость сильно просесть может), а дальше платформа отлавливает update conflict'ы и перестартует транзакции автоматически (пользователь этого не видит). Ну и там есть еще небольшая магия с sleep'ами чтобы deadlock'и разруливать (но это отдельная тема) и проверка классов (по сути удалением объектов) перед началом транзакции.

    Тут правда есть нюанс, что RR в версионнике сильно понижает целостность до уровня что 100% гарантируются только материализованные данные (здесь подробнее). Но тут как раз очень сильно помогает механизм прозрачных материализаций. Соответственно можно просто добавить материализации данных, для которых нужно обеспечить целостность, и они станут целостными автоматически. На практике же, так как материализации используются также и для оптимизации производительности, обычно их количества уже по умолчанию достаточно чтобы обеспечить целостность из коробки.

    Или вы что-то другое имели ввиду?
  • На пути к функциональной СУБД и NoSQL ERP: хранение остатков и расчет себестоимости
    0
    Ну провокации нужны, никто не спорит. Но не когда вы заявляете одно, а по факту получаете диаметрально противоположное :)

    То есть у вас как раз «анти-функциональная» — императивная СУБД таким образом получится.
  • На пути к функциональной СУБД и NoSQL ERP: хранение остатков и расчет себестоимости
    0
    Ну так у вас ключевые агрегации императивно задаются :) Причем тут тогда функциональная СУБД в заголовке? NoSQL да, но в такой постановке 1С с их регистрами функциональнее :)
  • На пути к функциональной СУБД и NoSQL ERP: хранение остатков и расчет себестоимости
    0
    Я не про то. Сама логика остатка (что это такое) у вас декларативно (функционально) или императивно задается? Можете ссылку на код, где задается что остаток это сумма приходов — сумма расходов сгруппированные по товару / складу?
  • На пути к функциональной СУБД и NoSQL ERP: хранение остатков и расчет себестоимости
    +1
    Есть магическая опция MATERIALIZED. Включаете ее и включается по сути ленивое вычисление. Само вычисление остатка при этом задается функционально. Вот в более классическом стиле с замыканием:

    receivedQuantity 'Суммарный приход' (Item i, Stock s) = GROUP SUM quantity(ReceiptDetail d) IF item(d) = i AND
    stock(receipt(d)) = s MATERIALIZED;

    А вы балансы императивно по сути заполняете. То есть получается «функциональщина» у вас в каких-то отдельных аспектах только есть.
  • На пути к функциональной СУБД и NoSQL ERP: хранение остатков и расчет себестоимости
    0
    В проекте лежит скрипт обновления балансов

    Ну то есть балансы вы предлагаете императивно обновлять, а не функционально. Как например тут: documentation.lsfusion.org/pages/viewpage.action?pageId=2228636
    Где вы в ФП задаете остаток, а дальше платформа все сама разруливает.

    То есть получается вы обеспечите функциональность в одном аспекте, а в остальных у вас будет такая же императивность как и везде.
  • На пути к функциональной СУБД и NoSQL ERP: хранение остатков и расчет себестоимости
    0
    Преимущества — экономим место за счет нормализации

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

    Свертки это все хорошо, но данные «хранимые строго упорядоченно со связями» кто заполнять будет? По факту, вы получите 1С регистры, которые просто сумму по измерениям умеют считать, а как помещать данные в / обновлять эти самые регистры, как там делать ограничения и т.п. — «я стратег, а не тактик», а вы разработчики крутитесь как хотите.
  • На пути к функциональной СУБД и NoSQL ERP: хранение остатков и расчет себестоимости
    0
    Если алгоритм оформлен как reduce() то вообще не проблема — появились новые данные, скармливаем редьюсу, и он досчитывает свой аккумулятор. Проблема, если алгоритм не ложится на reduce(), а представляет, например, SQL — тогда инкрементальные обновления это сложно, и нужна СУБД. Самый типичный отчет — сводная таблица, если в агератах функции типа sum(), эта штука легко досчитывается и даже параллелится, а если там count_distinct(), то досчитывается, но не параллелится, и т.д.

    Ну то есть только GROUP SUM по сути. А есть еще GROUP LAST, PARTITION, RECURSION, не говоря уже просто о композициях(JOIN) и арифметических/логических операциях. Задача на самом деле очень нетривиальная, прежде всего архитектурно. У Microsoft с Oracle ее решить не получилось. У нас же на нее лет 7 минимум ушло. А поверьте на одном GROUP SUM в ERP вы далеко не уедете.
    А вот исходные документы скорее останутся в бинарных файлах, так как СУБД отдают курсоры медленней чем файловая система

    Это экономия на спичках. Сейчас память настолько дешевая, что можно хоть всю базу в shared_buffers держать.
  • На пути к функциональной СУБД и NoSQL ERP: хранение остатков и расчет себестоимости
    0
    Ок, согласен, фокус в данном случае должен быть в ленивых вычислениях. Но их основная проблема в их обновлении при изменении данных от которых они зависят (инкрементальные обновления).

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

    Еще раз, то что вычисление идет в памяти не панацея. Современные СУБД спокойно забирают всю базу в память и тоже там выполняют все достаточно быстро. Проблема, когда одно и то же действие выполняется очень часто и сотнями разных пользователей. Как я уже писал узкое место в современных ИС не память, а процессор. И тут индексы единственное что может спасти.
  • На пути к функциональной СУБД и NoSQL ERP: хранение остатков и расчет себестоимости
    0
    Любой мьютекс на шаред-стейт приводит к ожиданиям потоков

    Не совсем понял. Ну включите уровень изоляции READ UNCOMMITED и будут у вас потоки читать грязные данные (по принципу что есть то есть) практически без блокировок. То есть параллелизм будет неограничен.
    хаскель, где в принципе запрещен стейт

    Вот тут есть доля лукавства. Данные то он откуда то берет для вычислений, эти данные и есть state.

    То есть если вам дать «фиксированную» SQL базу и политикой безопасности запретить DML (то есть разрешить только SELECT), вот вам и чистая функциональщина получится (тоже без state).
    Опять же, если вы свои алгоритмы строите на итераторах без мутабельных таблиц — вам намного реже нужны транзакции, тем более распределенные, таким образом еще одно узкое место отпадает.

    Но данные для вычислений откуда то должны браться.
    PS
    По предыдущей ссылке, респект, прочитал, но вы предлагаете языковое улучшение, а не смену парадигмы, поэтому ваш подход назвать функциональным можно с бОльшей натяжкой, чем мой.

    А можно уточнить тогда что вы подразумеваете под функциональным подходом? Чистые функции? Но данные все равно должны как-то попадать в систему, для их использования. То есть если взять тот же SQL, то SELECT — чистые функции, DML — подносчик снарядов для этих чистых функций. Вы же кстати в курсе что SELECT полон по тьюрингу и на нем можно любые вычисления реализовать.

    То есть по сути SQL (а точнее SELECT как его основной оператор) это и есть функциональный подход. И кстати причина почему он настолько популярен.
  • На пути к функциональной СУБД и NoSQL ERP: хранение остатков и расчет себестоимости
    0
    Если говорить конкретно про масштабирование, то random access ему никак не мешает. Основная проблема масштабирования это ACID и теория распределенных транзакций. Та же Master-Slave репликация много где идет из коробки и позволяет достаточно эффективно решать проблему масштабируемости. Основной фокус в Master-Master. Некоторые СУБД пытаются решать эту проблему (например Оракл со своим RAC) но там не все так однозначно.

    То что вы предлагаете это как раз увеличение производительности, за счет значительного упрощения и снижения оверхедов создаваемых SQL серверами (собственно это обычно и называют NoSQL). Но это подходит как раз для фейсбуков / инстаграммов с примитивной логикой, но очень большой нагрузкой. ERP это из другой оперы (я бы сказал противоположной). Вот Тут мы пытались все это немного систематизировать (насколько это в принципе возможно).
  • На пути к функциональной СУБД и NoSQL ERP: хранение остатков и расчет себестоимости
    +1
    Для меня сейчас главное — понять насколько сложным и (не) понятным будет прикладной код для типовых алгоритмов типа расчета себестоимости в производстве или MRP, сколько промежуточных данных придется нагенерить, какие будут связи между этими данными, и т.д.

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

    В SQL как раз все четко разделено. За изменение стейта отвечает DML, за вычисление данных SELECT. И если таблицу рассматривать как поток данных на нее вполне отлично ложится функциональщина. Подходы как раз очень схожи. Посмотрите хотя бы на LINQ в .Net. Мы с lair много на эту тему спорили. Вот пример как это в .Net скажем сделано.
  • На пути к функциональной СУБД и NoSQL ERP: хранение остатков и расчет себестоимости
    0
    Да не, все понятно. И функциональные подходы в разработке бизнес-приложений, действительно очень крутая штука, проверено на личном опыте. К вам то главный вопрос в другом. Зачем вы в NoSQL то все это компилируете. Почему не в SQL?

    Строго говоря разработчику все равно как это будет выполняться, если выполняться будет быстро и надежно. А у SQL все это есть из коробки. Собственно поэтому SQL по факту и стал стандартом в отрасли.
  • На пути к функциональной СУБД и NoSQL ERP: хранение остатков и расчет себестоимости
    +1
    Обычно так говорят, когда система не позволяет управлять сложностью.

    То что я видел, и по своему опыту с реально сложными логиками там будут проблемы, такие же как у условного 1С. А значит текущая их бизнес-модель на рынке среднего и крупного бизнеса не сработает. Модель 1С тоже не сработает, так как так консолидировать рынок они уже не смогут (рынок на западе уже в достаточно mature и конкурентном состоянии и нужно что-то более революционное).

    Ну и еще раз питон (как сам язык) это небольшая часть всей платформы (если мы говорим про платформы). Не надо переоценивать его роль. Есть еще штук 10 различных аспектов, где Odoo в чем-то лучше, в чем-то хуже. То есть может даже Odoo и лучше 1С, но не в 10 раз, а значит превратить brownfield в greenfield вряд ли ему удастся.

    PS: Например, если взять тоже наследование и полиморфизм в бизнес-приложениях ключевой момент там — поддержка полиморфизма в SQL слое, а это ни Odoo, ни 1С толком не удалось.
  • На пути к функциональной СУБД и NoSQL ERP: хранение остатков и расчет себестоимости
    +1
    Все не так просто. Бизнес-приложения это отдельный рынок, живущий по своим законам. 1С в нем наделал много ошибок, но остальные наделали их тоже достаточно, плюс рынок очень консервативный и инертный.

    Из тех кто удалось его хоть немного изменить, я знаю только Odoo — они как раз взяли что-то условно трендовое (python), навернули над ним свой фреймворк (на самом деле это самая важная часть, потому как синтаксис языка это дело второстепенное), сделали интерфейс более современным, ну и главное обеспечили хоть какую-то модульность и сделали маркетплэйс для разработчиков (аля отраслевок 1С). По итогу у них 16к модулей написанных сторонними разработчиками и уже 4 миллиона пользователей как у 1С. Но, надо понимать, что технологический потенциал Odoo ограничен, поэтому это строго говоря только малый бизнес (по западным меркам), ну и в принципе им даже на западе консолидировать рынок вряд ли удастся. Не говоря уже о том, чтобы сильно изменить уже частично консолидированный рынок в России (в тех сегментах куда они лезут).
  • На пути к функциональной СУБД и NoSQL ERP: хранение остатков и расчет себестоимости
    +1
    Ну во-первых, у них кроме ms sql, еще файловая и postgresql есть. И даже если под ms sql нормально работает, а под postgresql и файловую ложится для них это не выход.

    А, во-вторых, они весьма вольно обходятся с физмоделью / генерацией запросов (например в составных типах — эдаком суррогате наследования), вставляя туда OR'ы с CASE'ами, где даже MS SQL начинает конкретно чудить.
  • На пути к функциональной СУБД и NoSQL ERP: хранение остатков и расчет себестоимости
    0
    Так в любой ERP количество промежуточных данных на порядок больше количества документов

    С промежуточными данными вы явно преувеличиваете. В 1С остатки хранятся для промежуточных периодов (по умолчанию по дням ЕМНИП, а потом по месяцам) и то только потому что а) они пытаются аналитику за далекие периоды в оперативную базу положить б) у них все очень плохо с оптимизацией запросов (в частности predicate push down'ами) и не храни они промежуточные итоги, с производительностью все было бы куда хуже. Так что это не показатель.

    Остальные системы в основном хранят только актуальные остатки, а дальше обратным счетом рассчитывают показатели на нужные даты.
  • На пути к функциональной СУБД и NoSQL ERP: хранение остатков и расчет себестоимости
    +1
    Неспроста придумали и старательно форсят функциональное программирование — оно не про скорость, оно про надежность и тестируемость кода.

    А причем тут функциональное программирование? Это классная штука не спорю, но его можно одинаково «компилировать» как в SQL (что многие и делают) так и в NoSQL. И причин «компилировать» все в SQL куда больше, прежде всего из-за важных оптимизаций (с индексами и параллелизмом) и ACID из коробки.
  • На пути к функциональной СУБД и NoSQL ERP: хранение остатков и расчет себестоимости
    +1
    А у вас эти 200кк записей не в памяти (в shared_buffers или как они там в ms sql называется)? Потому как если вся таблица в памяти, там цифры куда меньше будут.
  • На пути к функциональной СУБД и NoSQL ERP: хранение остатков и расчет себестоимости
    +4
    У них всех узкое место — блокировки

    Так их не от хорошей жизни делают. А именно потому что в ERP целостность данных действительно важна. Тут если остаток поплывет, это будет очень плохо (куда хуже чем незагруженная фотка в условном инстраграмме). И как раз версионные СУБД с их оптимистичными блокировками позволяют более менее эффективно решать проблему целостности, не сильно жертвуя масштабируемостью. То что многие учетные системы используют ручные пессимистичные блокировки это конкретно кривость рук их разработчиков, но вы то же предлагаете тоже самое.
    и неконтролируемое расползание ошибок пользовательских алгоритмов по сотне таблиц (из тысячи штатных)

    Это решается построением еще одного уровня абстракции над SQL. Но никак не переходом на NoSQL, где с этим может быть все еще хуже.
    Изменить схему хранения данных, поле добавить — выгоняй пользователей на час, и т.д.

    Вообще ЕМНИП СУБД позволяют очень много вещей делать не выгоняя пользователей. Не говоря уже о том, что динамическое изменение структуры по ходу и надежность — это противоположные вещи.
    Мне нужна биг-дата ERP

    Вообще у вас странная ERP. 24x7 (что уже редкость), с петабайтами данных и триллионами транзакций (что строго говоря для SQL на примитивной логике тоже не проблема, вспомните убер) и с логикой где не нужны выборки по условиям и целостность данных. Вы уверены что такие ERP существуют? И вообще в моем понимании ERP это именно что сложно-функциональные бизнес-приложения с высокими требованиями к целостности. А что это в вашем представлении?
  • На пути к функциональной СУБД и NoSQL ERP: хранение остатков и расчет себестоимости
    +1
    1) Не совсем понял про цену? Каким образом цена перебора всех данных соизмерима с поиском по нескольким индексам? У них алгоритмическая сложность на порядок отличается (один — n, второе log(n)). Вы наверное забываете, что сейчас процессор узкое место (так как их производительность практически не растет), с памятью (со случайным доступом, как оперативной так и постоянной (SSD)) сейчас проблем нет, и можно хоть всю SQL СУБД в память положить. То есть закладываться на медленные последовательные HDD (и большой оверхед на долгое чтение блоков) в современном мире никакого смысла нет.

    Ну и не понял зачет этот огород со смещениями и seek и read, если SQL умеет это делать сам и из коробки.

    2) Ну то есть ручные пессимистичные блокировки. Опять-таки SQL это из коробки, а главное куда эффективнее за счет оптимистичных блокировок умеет делать.

    То есть я так и не понял чем вас SQL не устраивает?
  • На пути к функциональной СУБД и NoSQL ERP: хранение остатков и расчет себестоимости
    +3
    Это все конечно классно, но вопрос, как вы собрались производительность без индексов обеспечивать? То есть нужно оборотную ведомость по одной группе товаров с даты по дату сформировать. SQL может построить план с пробегом по индексам, в том числе составным. А как вы это в NoSQL делать собрались?

    Ну и с ACID я так и не понял, что вы собираетесь делать. У SQL есть вполне декларативная и простая модель с блокировками (более) или update conflict'ами при RR/SERIALIZABLE уровнях изоляции. Как вы тот же остаток предлагаете целостным поддерживать?
  • Почему нужна инструментальная поддержка пагинации на ключах
    0
    Это достаточно простой функционал на самом деле.

    Кстати, чтобы не пролетать мимо планов есть куда эффективнее способ сначала читать ключи, потом читать колонки. Чуть подробнее в недавней статье.

    Ну и еще круче на самом деле отбрасывать сложные фильтры без индексов, находить более широкое «окно» на простых фильтрах для которых есть индексы, а потом добавлять это «окно» в фильтр, чтобы это окно протолкнулось в эти сложные фильтры (чтобы они расчитывались не для всей базы). Но пока так даже lsFusion не умеет, хотя вся инфраструктура для этого есть, возможно в будущих версиях и появится.
  • Пошаговая инструкция настройки обмена через файл между 1С: Управление торговлей 11 и 1С: Бухгалтерия 3.0
    0
    Каналы связи очень любят падать.

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

    Ну мы сажаем, причем огромные базы с тучей оборудования. Правда не на 1С.
  • 1С-Битрикс и попытка его внедрения
    0
    Ну под получше я и имел ввиду с учетом TCO.

    Про дно естественно согласен, но я реально знаю достаточно случаев, когда выбирали по критерию лишь бы «на 1С» / «не на 1С». Но человеческая глупость как известно не имеет границ.
  • 1С-Битрикс и попытка его внедрения
    0
    Это пять :). Хотя мне кажется это экстремализм давать таким сотрудникам доступ к коду и возможность его менять прямо в продакшне. Я надеюсь у него эти права сразу забрали?
  • 1С-Битрикс и попытка его внедрения
    0
    Опять же, никто так не говорит. Говорят, что «всегда можно найти программиста, который знает конкретный продукт».

    Ну вы же понимаете, что это принципиально все меняет. Потому как в таком случае смысл все делать на одной платформе теряется практически полностью. То есть грубо говоря если есть CRM на условном php чуть получше, то логично брать его, а не CRM на 1С (просто потому что на 1С). То же самое касается и всех остальных модулей.
  • 1С-Битрикс и попытка его внедрения
    0
    Вообще если вы перечитаете мой комментарий, то увидите, что я писал не конкретно про вас, а вообще про всех (в том числе про меня). Скорее иронизировал над тем как устроен рынок.
    вы взяли мнение (кого? откуда?) про «сел и поехал»

    Мнение автора до внедрения, ну и собственно расхожее мнение на рынке.
    на что? из-за чего упущена прибыль, если у него уже была система автоматизации до покупки Битрикса и УТ?

    Ну это не ко мне вопрос.
    сделали вывод, что «забавно меняется мнение» (чье?)

    В данном случае я имел ввиду мнение в процессе обсуждения. Хотя да наверное не совсем правильно выразился (меняется не правильное слово). Я имел ввиду, что даже в рамках одного сообщества, мнения о сложности или важности определенных вещей абсолютно полярные. Без оценки хорошо или плохо, просто констатация факта.
  • 1С-Битрикс и попытка его внедрения
    0
    Ваш стандартный ответ на это — «три строчки кода написать».

    Вообще как раз все вопросы к решениям и сводятся к поддержке местного законодательства (всяких ЕГАИС), которые по вашим же словам: «не существенные разовые доработки» (то есть те самые «три строчки кода») И если так считать, то решения для розницы скажем у нас есть и успешно работают у достаточно большого количества крупных компаний. Хотя да сейчас идет разработка бесплатного аналога Odoo / МойСклада / УНФ, которое будет не только для розницы, правда только для малого бизнеса. Плюс фундаментом для более сложных решений (по модели оду), благодаря очень высокой модульности.

    Но это все к теме мало относится.
    Про «дорого», «тяжело» — это понятия относительные во-первых, во-вторых опять придуманные вами.

    Что значит придуманные мной. Вот слова автора:
    К сожалению, в целях экономии денег и будучи «продвинутым» пользователем я решил самостоятельно заниматься внедрением этих продуктов. Сколько в итоге было впустую потрачено сил и упущено прибыли, не счесть. Не делайте так, пользуйтесь услугами интеграторов.

    И это компания всего на 25 сотрудников.
  • 1С-Битрикс и попытка его внедрения
    0
    P.S. забавно читать про «он что, на стороне должен механика найти», от компании, которая не продает коробочные продукты и вовсю топит за «бизнес должен нанимать профильных аутсорсеров, т.к. у них есть компетенции».

    Кстати забавно как в таких темах быстро меняются мнения, от «самое главное это поддержка местного законодательства», до — берите решение из другой страны, а вся поддержка местного законодательства это «не существенные разовые доработки». И от «сел и поехал», до «без внешнего специалиста внедрить очень дорого и тяжело».
  • 1С-Битрикс и попытка его внедрения
    0
    А вы реально пробовали, когда нибудь изучать доработки по истории изменений (для составления общей картины). Annotate (или как это называется в 1С) используется обычно для сугубо локальных целей (особенно после какого то количества изменений), типа «а кто это сделал». То есть чем расширения помогают избавиться от вендор-лока того кто дорабатывал систему непонятно. То есть может и помогает, но совсем немного чтобы говорить, что а вот с 1С у вас его не будет. Это не более чем иллюзия. Я точно также думал про электриков скажем, пока не столкнулся с ними лично.
  • 1С-Битрикс и попытка его внедрения
    0
    Объект копируется в расширение, и там с ним можно делать что угодно

    Ну тогда чем это отличается от обычной диффграммы в любой системе контроля версий. И еще более непонятно чем это поможет в изучении доработок. Когда количество изменений становится больше какого то уровня, их список / история практически не помогает.
    Менять стандартные обработчики на свои с директивами &Перед, &Вместо, &После, добавлять параметры и реквизиты, в т.ч. и в регистры.

    Непонятно чем это поможет, если скажем нужно параметр протянуть по стеку. С регистрами я имел ввиду если надо новое измерение добавить глобально. Чем эти аспекты там помогут?
    В динамический список параметр вообще добавляется стандартной процедурой БСП

    Причем тут параметр, я про соединение и поле в запросе говорил. Если вы просто перегрузите произвольный запрос, у вас при обновлении поля / соединения добавленные в него в типовой затрутся. Хотя может я не понял о чем речь, поделитесь ссылкой что именно вы имеете ввиду?
    Очевидно потому, что расширений просто не было на момент создания тех решений.

    А может просто потому что этот механизм очень ограниченный и не подходит для создания модульных решений.
  • 1С-Битрикс и попытка его внедрения
    0
    все можно сделать расширение конфигурации

    Да прям таки. Например в существующий запрос (в коде или в произвольном запросе динамического списка) еще одно поле / соединение как добавить? Или еще один параметр в процедуру. Или еще одно измерение в регистр. И таких вопросов очень много. Сейчас расширения и обработки это пару частных случаев.

    Не говоря уже о том, что расширения в том виде, котором они сейчас в 1С, никак не делают их решения не монолитом (то есть почему по вашему они сами их не используют для декомпозиции своих решений?).
  • 1С-Битрикс и попытка его внедрения
    0
    Зависимость от конкретного человека и его программы все-таки гораздо опаснее, чем от 1С.

    Вы не поняли, речь шла о том, что при доработке любого решения появляется та же зависимость от того кто его дорабатывал. И не так важно было там что-то «типовое» в основе или нет. Тем более что у самого типового технический долг очень неслабый а помноженный на доработки даст не меньший эффект чем даже в случае с самопиской.
    Даже дорабатывать можно так, чтобы она без проблем обновлялась.

    Ну учитывая, что код на 1С это жесткий императивный низкоуровневый монолит, то только в каком-то идеальном мире.