1С под Linux : 1С: Управление торговлей

Зря, ) там наверное много интересного.

Это у меня начальство по нормальному работать решило. Верю. ;)

О, греат сенькс Петрову Володьке. Я с ним больше работал. :)

ЗЫ, Но самому-то интереснее ваять же. :)

В этом и фикус. Берешь любой язык и пишешь.. А то, что в 1С внутренний, то это ... *112

Лично я все это помню. Когда Олег был где-то далеко на севере, там было 2 часа ночи, плюс кто-то (к сожалению, не помню, кто это был) в Москве помогали мне приводить базу в работоспособное состояние. Благодарен Олегу за все, что он для нас сделал.

Как человек, который давно работает с 1С и только 3 года с Супермагом хочу внести свои 5 копеек.

Конфигуратор, увы не только благо, но и бич. И вот почему: Визуальное конструирование форм, и построение на их основе таблиц данных приводит к невозможности оптимизировать быстродействие на уровне самой базы.
Если в См2000 при открытой структуре данных можно ускорить формирование отчетов, например, за счет партицирования таблиц, то попробуйте проделать подобную процедуру в 1С любой версии. Удачных реализаций, если честно, очнь и очень немного...

Что касается быстроты разработки.

Приблизительно одинаковое время затрачивается, чтобы написать отчет в 1С 8-ой версии с нуля, и в Oracle Reports.
И там и там все вопросы - правильно написать запрос.

Остальные вещи зависят только от квалификации программиста.

Внешние компоненты никто не отменял. ;)
Вопрос в другом, смотри. Тебе надо что б твоя приходная накладная имела еще 1 столбец. Как можно это реализовать в СМ? :)

Быстродействие достигается за счет оптимизации хранилища. К примеру Скуля. К немуже можно делать прямые запросы.

Насчет 8-ки, она имеет встроеный мини OLAP, Кучу конфигураторов, и почти вся разработка идет мышью. Извини, но репортс отстает на порядок. ПО удобству.

Если нужно быстродействие нужно писать на асме. Жалею, что не знаю его. :(

Ты знаешь, мне за 3 года работы с См2000 доп.столбец в приходной накладной ни разу не понадобился...
Обычно такие вещи просят сделать, если не понимают логику ПО.
Правда 1С это тоже касается...

Объясняю реальный пример. Требуется создать документ, который орагизовывал бы бумажный вариант "Договора по согласованию цен". Нормальной реализации онного в СМ не найти.

Опять же я хочу видеть старую цену и новую в ОДНОМ документе. ОДНОВРЕМЕННО. Опять же этого СМ не мог.

+ много мелочей. Доработки ВСЕГДА необходимы компании, где работают профф. менеджеры. Или не стандартные ситуации.

Опять же, за время автоматизации (не использования, а именно автоматизации, внедрение + переход с СМ и Раруса на единую платформу) сети магазинов на 1С. В саму компанию я обратился 1 раз. (Был косяк с загрузкой данных из бэкапа). Больше не возникало ни одного случая, когда бы мне этого потребовалось. :) С СМ-же ситуация немного иная. Открыть магазин - легко, но рано или поздно начинает колбачить оракл, начинаются какие-то извращения с обрезками, какие-то моменты связанные с доработкой. Поэтому его "+" уходят на нет. :( К сожаленью.

Думаю что если ты спец по 1С, то надо допускать что есть такие же спецы по Oracle и его языку PL/SQL, которые описанную тобой ситуацию в два счёта реализуют, а про 1С скажут тоже самое что ты говоришь про Oracle и СМ.

"колбачить оракл" начинает в том случае если на него забить, "при правильном уходе и кормлении он вам прослужит долго верой и правдой"
Насчёт извращений с обрезкой, то я могу сказать (и мои слова подтвердят участник), что сама платформа Oracle прекрасно тянет базы большого объёма, что позволяет собирать аналитические отчёты за большие периоды. Извращения заложены в саму процедуру от С+, но эти извращения кому-то были нужны.