strizh
Мне конкретно не нравится в 1С 8.1 и 8.2 следующее.
1) Названия перечислений хранятся в конфигурации, а не в БД

Это так, но мы например сделали в БД дополнительные вьюхи для перечислений и это несложно кстати.

strizh
2) Конфигурация и метаданные хранятся не в БД, а отдельно на диске

Они хранятся в БД, правда в виде блоба. Это действительно очень плохо (в частности операции сравнения разных версий одного отдельного объекта дико тормозят).

strizh
3) Системные логи хранятся не в БД, а в файлах на диске

Это плохо, но есть несколько кастомных версий систем логирования, которые пишут логи в БД. Нампример та, которая теперь в УПП. Мы тоже себе сделали. Механизм

strizh
4) При даже незначительных изменениях конфигурации нужно снимать сеансы всех юзеров, причем даже работающих через сервер приложений и даже работающих через web-интерфейс 8.2. Последнее - совсем печально.

Это не так. Если изменения не затрагивают структуру хранения данных (изменения в модулях, формах и т.д.) можно апдейтить конфигурацию "на ходу". С измененой версией правда будут работать только те пользователи, которые вошли в ситему позже изменений.

strizh
5) Названия полей в таблицах нельзя сделать человечными - они задаются только автоматически

Но можно автоматически нагенерить вьюхи на все таблицы с вменяемыми именами вьюх и полей, что мы и делаем.

strizh
6) Нельзя в БД применять сторонние вьюшки и таблицы, не описанные в метаданных

Тора не велит? Вообще применять можно. Тольбко работать с ними нужно через ADO.

strizh
7) Не применяются средства поддержки целостности уровня СУБД

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

strizh
8) Не применяются механизмы реприкации уровня СУБД

Да, но встроенный в 1С механизм репликации будет куда поюзабельней.

strizh
9) Вместо языка SQL применяется некое русское убожество, разбираться с которым ну совсем некошерно.


Ну, опять религиозные проблемы. Вполне себе диалект SQL. Английский вариант синтаксиса есть. Конструктор запросов - просто прелесть. Хотя конечно having не хватает, апдейта и пользовательских функций. Правда при большой желании можно слазить к базе напрямую через ADO и выполнить "нормальный" запрос.

strizh
10) Связь с AD с целью авторизации юзеров - начальный уровень. А хотелось бы иметь возможность назначать эквивалентность групп в AD ролям в системе защиты 1С
Это да.

P.S. Мне вот в 8.1. больше всего не хватет доступа к значению поля формы до измения в событии "ПослеИзменения". Мелочь, а так неудобно ...

Rsvcoderskmdeveloper, отвечу вам на первоначальный вопрос для того, чтобы вы оценили проблемы какого уровня не решены в 1С
1) декомпиляция всех метаданных в текстовые файлы, по аналогии проекта gcomp, с возможностью послеющей компиляции
2) сравнение модуля с версией хранилища без получения из хранилища всей конфигурации, т.е. быстро
3) возможность изменения текста модуля без необходимости перезапуска клиента

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

Это то, что затруднительно сделать без 1С, а 1С этого делать не хочет. В свою очередь отсутсвие этих вещей мешает дорабатывать платформу без 1С. Мы же отвечаем на вопрос "что вам не нарвится в 1С", а не "стоит ли мне браться за безнадежное дело".

Сисой
А в десятках других систем изменение конфы оповещает сигналом рабочие процессы и они начинают работать с новой бизнес-логикой автоматически. Даже в аксапте - гораздо лучше сделано. Что мешает сделать это 1С?

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

Сисой
skeptik
Но можно автоматически нагенерить вьюхи на все таблицы с вменяемыми именами вьюх и полей, что мы и делаем.

И как - под майонезом вкусные кактусы получаются?

Очень, пальчики оближешь! В данном случае проблем действительно никаких (но наше решение привязано к платформе MS SQL).

Сисой
skeptik
6) Нельзя в БД применять сторонние вьюшки и таблицы, не описанные в метаданных

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

Видимо да, не велит. Возможно опасаются, что если стаблицей в БД начнут работать какие-либо другие приложения кроме 1С одновременно с 1С то возникнут неконтролируемые со стороны 1С проблемы с блокировками.

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

Сисой
Мне не хватает:
а) Дополнительных подключаемых обработчиков в форме (по аналогии с подпиской на проведение или запись). Это упростило бы модификацию типовых.
б) Нормальной технологии управления версиями и внесения изменений.
в) ООП (с наследованием структуры таблиц).
[/quot]
Поддержу. Причем наиболее критичен пункт б)