Подробнее пожалуйста. Директум, это инструмент для конечного клиента. С - инструмент для создания директума. Или что имел в виду?

Именно. Но в случае с Директумом там не всё так ясно. Похоже первые версии делались на Дельфях, последние планируют на шарпе + .NET.

Если бизнес-процессы предприятия не будут меняться в соответствии с изменениями во внешнем мире, то все оптимизации впустую. Например недавние изменения в соответствии с законодательством по новым корректировочным С/Ф затронули бухгалтерию, бюджетирование и фин планирование (это и есть составляющие ERP системы). На 1С-е на все про все ушло 1-2 месяца. Это время выяснения тонкостей законодательства.

Да это самая большая проблема. Если бы всё было так просто и однозначно. Вообще существует несколько подходов для решения этой проблемы: 1) создать продукт максимально вобравший в себя всё что только возможно из жизни. Примущества как и недостатки очевидны. 2) создать продукт, который имеет встроенные средства разработки. Классический пример 1С. Да и все современные системы (учетные и прочие) поступают таким же образом. Преимущества: имеется возможность в любой момент внести изменения в работу программы на любом уровне. Недостаток: за все приходиться платить. Такие системы работать МЕДЛЕННО, ибо являются неоптимизированныеми интерпретаторами. 3) создать не конечный продукт, а некий фреймворк, оперирующий стандартными объектами в инфолрмационной базе и с кучей доп. функций в том числе в плане постороения интерфейса. Преимущество: скорость работы, возможность расширять систему вносить изменения. Недостататки: требуется высокая квалификация программиста.

Теперь попробуй оценить сколько на сях времени уйдет. Соответственно ни кто такую ERP себе не поставит, что бы не быть костным

У меня созаеьтся впечатлени, что ты несколько неверно воспринимаешь Си-шарп. Это не панацею от всех бед. Это не язык для программирования баз данных или учетных систем. Это высокоуровненый язык для общего программирования. Как правило на нем не пишут с нуля системы. Ну если только редко. Берётся готовый фреймворк облегчающий манипуляции с БД и, оперируя объектами базы данных, создается необходимая логика. Если ты знаешь как работает фреймворк (а это как правиль так и есть), то не составляет особо труда увидеть где надо внести изменения в логику. Заниматься кропотливым кодированием не придется ! Такая работа мало отличается от написния модулей в 1С. Единственный нюанс то, что средства разработки и отладки (в 1с они в комплекте) придется использовать не поставляемые с ПО. Как правило это Visual Studio. А это стоит отдельных денег. Да и найти толкового .NET программиста слежнее чем 1с-ника. Вашей братии расплодилось как мух на говне (прощу прошения за сравнение).

Ну что за мерки то? У нас только ОС около 1 000 000. У каждого ОС около сотни свойств, а это отдельные сущности, т.е. куча таблиц и записей. Помимо ОС в конфигурации несколько сотней подобных сущностей (справочники, документы и т.д.)

Во-первых, у меня файл-серверное решение и для такого решения 1.5 млн записей весьма солидно, во-вторых, ОС является справочником. Справочник по-определению используется в самый поледний момент выборки. Так-что 1 млн записей в справочнике не показетель. Я же говорю про таблицу в которой храняться движения и на основе которой делабются все последующие выборки, остатки и пр.

Взять те же итоги, на сколько эффективны у тебя промежуточные итоги? Или любой запрос подразумевает полный пересчет?

Промежуточные итоги не есть благо. Это одно из возможных решений для снижения объема выборки. Такое решение диктуется отсутствием здравого механизма оптимизации выборки, ерационального использования индексов. Например, 1с создает простые индексы по каждому полю, но (!) если скажем в выборке задействованы постоянно несколько одних и тех же полей, то следует создавать индекс по значениям этих полей, чего 1с не делалал, не делает и, скорее всего, не сделает. Она так и будет шарить по имеющимся индексам. И исзменить это положение дел невозможно. Правда про SQL версию говорить не буду. Это отдельный рахговор. Потому и 1с-ники и налепели ПИ. Что касается лично моей реализации, то итоги по товарм формируются в момент сохранения документа. От практики полного пересчета я отказался. Объемы стали давать о себе знать. Что же касается взаиморасчетов, то они по-прежнему получаются на выборкой. Ничего промежуточного не храниться. Работает, как ни странно, быстро. Может потому что оптимизирована структура хранения данных.

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

Это вопрос не сертификации по 1с, а умея программировать вообще. Это каждому дано. И среди 1с-ников полно говнокодеров. да где их нет ? Они везде !

У меня напарники каждый день работают в америке, пишут инет-магазины. Так вот там 1С нет не потому что их 1С-ка дорогая очень. ОЧЕНЬ!

Во-первых, дествие пословицы "скупой платит дважды" никто не отменял, во-вторых, 1с им не поможет в любом случае. Ибо возможность интеграции в 1с появилась только с версии 8, до того никак кроме дрочильни "выгрузить-загрузить данные" не было !

Мало того, сейчас конфа на 1С будет прекрасно работать как в виде клиента и сервера, так и в виде веб клиента.

Не будет. В 8-ке есть лишь WebServices, их к HTML надо еще прикрутить. Поменяется логика в базе, надо будет менять и HTML. Ну это в обещм случае, без конкретики.

Ни чего переписывать не надо. Реально, остальные нервно курят в сторонке.

Переписывать надо и многократно. Чудес на свете не бывает. И никто в сторонке курить не будет.

А масштабирование у 1С:8.2 на столько гибкое

Масштабирование к гибкости не имеет никакого отношения ! Тебе как программиста околобазданных это надо знать в первую очередь. Масштабируемость - это свойство системы не снижать производительность при увеличении числа запросов. Существует лишь два способа его обеспечения: использования SQL сервера и использование терминального решения. Есть еще третье - комбинация SQL сервера + терминальное решение. Ладно. Приятно было пообщаться. Удачи.