Здравствуйте, AndrewVK, Вы писали:

AVK>>>Поскольку действие там ровно одно — проведение, то и идентификаторов никаких не надо.
A>>Ну вот смотри. У нас есть Документ (в "ревизии" 0). Над ним произвели 5 действий (получился документ в "ревизии" 5). Эти 5 действий представлены 5-ю Регистрами.
AVK>Ничего не понял. Какие, нафик ревизии и какие 5 регистров? При каждом изменении документа все записи во всех регистрах, связанных с ним, удаляются. При повторном проведении — добавляются по новой. Никаких ревизий.
Короч, надо читать документацию по 1С...

A>>А правильно ли будет провести анлогию в VCS: Документ == файл под контролем, Регистр == набор изменений для конкретного файла?
AVK>Нет. Ты вообще, хотя бы примерно, представляешь себе, что такое OLAP/OLTP кубы?
Примерно -- да

Здравствуйте, AndrewVK, Вы писали:

A>>А атрибуты чем от этого отличаются? По мне это тот же атрибут, только табличного типа.

AVK>Это по тебе. А по мнению авторов 1С — нет.

Ну, это не принципиально с точки зрения модели, хотя и заставляло идти на разные выкрутасы вроде составных документов. Говорят, в 8-рке это наконец исправили. Вообще, так не должно быть. Я бы предпочел видеть в лице документа и справочника произвольный JSON-объект. И prototype-based объектную модель хранилища. И это, JavaScript вместо языка 1С. И штоб работало в браузере. Это была бы сказка.

AVK>>>Поскольку действие там ровно одно — проведение, то и идентификаторов никаких не надо.
A>>Ну вот смотри. У нас есть Документ (в "ревизии" 0). Над ним произвели 5 действий (получился документ в "ревизии" 5). Эти 5 действий представлены 5-ю Регистрами.

AVK>Ничего не понял. Какие, нафик ревизии и какие 5 регистров? При каждом изменении документа все записи во всех регистрах, связанных с ним, удаляются. При повторном проведении — добавляются по новой. Никаких ревизий.

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

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

Кстати, еще одна крутая придумка 1С-ников. Вы можете ввести документ "на основании" любого другого, в этом случае при его создании отработает "конструктор копировая", который вы сами пишете. Workflow изображается элементарно — в визуальную форму документа, который соответствует состоянию workflow, добавляются кнопки "вводов на основании", которые позволяют из него перейти к следующему действию. Есть еще варианты.

Здравствуйте, Gaperton, Вы писали:

G>Ну да, надо добавить, что никто действий над документами не производит. Сам документ — это действие.

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

G>Кстати, еще одна крутая придумка 1С-ников. Вы можете ввести документ "на основании" любого другого

Это не 1С придумал, эта фича есть в куче другого управленческого софта.

G> Workflow изображается элементарно — в визуальную форму документа, который соответствует состоянию workflow, добавляются кнопки "вводов на основании"

В реальных системах все может быть намного круче и гибче, чем в 1С. См. например "процессный подход".

Здравствуйте, Gaperton, Вы писали:

G>Ну, это не принципиально с точки зрения модели, хотя и заставляло идти на разные выкрутасы вроде составных документов. Говорят, в 8-рке это наконец исправили. Вообще, так не должно быть. Я бы предпочел видеть в лице документа и справочника произвольный JSON-объект. И prototype-based объектную модель хранилища. И это, JavaScript вместо языка 1С. И штоб работало в браузере. Это была бы сказка.

Главное что бы операторы по Русски. На каком языке думаю на том и пишу. А по поводу составных документов то и на 7.7 это несложно делать. А еще неплохо вывод типов, интеллисенсе синтаксический контроль.
По поводу разделения Документа и справочника то различе в них только в проведении. А так справочник отвечает за постоянную состовляющую, документ за уникальную. Иерархия и там и там существует. Для документов ввиде подчиненных документов.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Gaperton, Вы писали:

G>>Ну да, надо добавить, что никто действий над документами не производит. Сам документ — это действие.

AVK>Не совсем так. Сам документ в 1С все таки очень часто 1 в 1 соответствует реальному бумажному документу. То, о чем ты говоришь, есть в других системах, там основой является как раз таки действие (например бухгалтерская проводка), а документ может даже восстанавливаться на основе проводок. В 1С же все наоборот, документы первичны, действия вторичны.

В 8 есть документ отображения регистра, а для проводок существует операция. Но так или иначе это документы, но содержимое отображается в регистры (бух итоги) без преобразования.

Здравствуйте, Serginio1, Вы писали:

S>Здравствуйте, Gaperton, Вы писали:

G>>Ну, это не принципиально с точки зрения модели, хотя и заставляло идти на разные выкрутасы вроде составных документов. Говорят, в 8-рке это наконец исправили. Вообще, так не должно быть. Я бы предпочел видеть в лице документа и справочника произвольный JSON-объект. И prototype-based объектную модель хранилища. И это, JavaScript вместо языка 1С. И штоб работало в браузере. Это была бы сказка.

S>Главное что бы операторы по Русски. На каком языке думаю на том и пишу.

Операторы и переменные по русски — это на самом деле очень круто. Сначала колбасит с непривычки, зато потом понимаешь, что это потрясающе удобно. Можно очень креативно называть функции и переменные, раскрыв весь активный словарный запас.

> А по поводу составных документов то и на 7.7 это несложно делать.

Технически — да. Однако, были определенные проблемы с организацией ГУЯ, связанные с тем, что в документе и элементе справочника нельзя было вляпать произвольную табличную часть. С появлением контрола таблицы выкрутится можно было всегда, но это было связано с лишением халявы, в виде автоматического data binding, который надо было делать в ручную. А я, когда программил на 1С, очень не любил лишаться халявы — 1С тем и крут, что persistence и data binding полностью автоматический. Когда приходится таблицы руками наполнять — не по 1С-сному это как-то получается, некошерно. Обычно, я предпочитал изменить модель данных, чтобы избежать ручного binding-а.

Здравствуйте, AndrewVK, Вы писали:

G>>Ну да, надо добавить, что никто действий над документами не производит. Сам документ — это действие.

AVK>Не совсем так. Сам документ в 1С все таки очень часто 1 в 1 соответствует реальному бумажному документу.

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

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

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

ИМХО, в 1С сделали правильный выбор. Так удобно. Если надо — то бить документы на отдельные документы, которые проводятся группой — можно, и ничего страшного в этом нет.

G>>Кстати, еще одна крутая придумка 1С-ников. Вы можете ввести документ "на основании" любого другого

AVK>Это не 1С придумал, эта фича есть в куче другого управленческого софта.

Вполне возможно. Даже наверняка.

G>> Workflow изображается элементарно — в визуальную форму документа, который соответствует состоянию workflow, добавляются кнопки "вводов на основании"

AVK>В реальных системах все может быть намного круче и гибче, чем в 1С. См. например "процессный подход".

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

Здравствуйте, Gaperton, Вы писали:


>> А по поводу составных документов то и на 7.7 это несложно делать.

G>Технически — да. Однако, были определенные проблемы с организацией ГУЯ, связанные с тем, что в документе и элементе справочника нельзя было вляпать произвольную табличную часть. С появлением контрола таблицы выкрутится можно было всегда, но это было связано с лишением халявы, в виде автоматического data binding, который надо было делать в ручную. А я, когда программил на 1С, очень не любил лишаться халявы — 1С тем и крут, что persistence и data binding полностью автоматический. Когда приходится таблицы руками наполнять — не по 1С-сному это как-то получается, некошерно. Обычно, я предпочитал изменить модель данных, чтобы избежать ручного binding-а.
Я это к тому, что до сих пор сижу на 7.7, а смысла особого напереходить на 8 нет на предприятии где работаю нет (а за новшества я двумя руками за). Вернее смысл есть, только не стоит это тех трудозатрат на переход.
Просто недавно нужно было сделать в одном документе трёх уровневое подчинение в документе. Через Тз это решается, и если данные однотипны , то документ практически хранит одни данные. Это так к слову. Приходится выкручиваться, для удобства пользователей, а они ещё и не ценят. Иногда даже полезно лишаться халявы, для тренировки мозгов. Да и как шаблон такой документ можно использовать многократно. А так я давно жду новый компилируемый виток 1С, хотя скорости то хватает, а там где ее нет прямой доступ и Вк (для Sql прямыми запросами вытащить данные, а на клиенте уже обработать, хотя и 1С++ во многом хватает).
Для SQL жду недождусь когда же можно применять объектный подход на стороне сервера. Тогда системы типа 1С могли бы работать с огромным количеством юзеров. Потому, что так или иначе объектный подход к развитым по структуре хранилищам данных, имеющие неопределенные типы данных (Справочник, документ итд). А работаю, я все на 1С 7.7

Здравствуйте, Gaperton, Вы писали:

G>С удовольствием посмотрю, особенно если ты дашь ссылку. Сдается мне, по сочетанию "процессный подход" не так просто что-либо конкретное найти.

К сожалению, ссылок я не коллекционирую, поскольку данная тема находится за пределами моей компетенции. Единственная ссылка, какая у меня есть — http://www.parus.ru/index.php?page=276

Здравствуйте, IB, Вы писали:

IB>Здравствуйте, Cyberax, Вы писали:

C>>А так ведь всё равно придётся, хоть ты с напрямую в сетевой провод биты насвистывай.
IB>Чтобы не пришлось, надо не насвистывать, а явно открывать и закрывать соединение с базой при каждом обращении — дешево и сердито, и никакой ручной синхронизации потоков с приседаниями вокруг сессий.

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

Здравствуйте, michael_isu, Вы писали:

_>Здравствуйте, IB, Вы писали:

IB>>Здравствуйте, Cyberax, Вы писали:

C>>>А так ведь всё равно придётся, хоть ты с напрямую в сетевой провод биты насвистывай.
IB>>Чтобы не пришлось, надо не насвистывать, а явно открывать и закрывать соединение с базой при каждом обращении — дешево и сердито, и никакой ручной синхронизации потоков с приседаниями вокруг сессий.

_>Делаю сейчас модуль онлайн-тестирования студентов. В текущей схеме есть целый граф объектов, часть из которых грузится лениво, часть — явно. Чтобы по нескольку раз не дергать СУБД, однажды загруженные данные сохраняются в сессии (вопросы тестирования, ответы и т.д.). Это более медленный и кривой вариант, чем если бы за каждым элементом данных приходилось лезть в БД снова и снова?
Используя сессию вы значительно уменьшаете scalability своего приложения. Это касается даже не кластеризации, когда приложение разворачивается более чем на одном компе, а банального shared хостинга. С увеличением числа пользователей объем хранимых сессий постоянно растет и вы рискуете вылететь за ограничения, что потребует от вас больших расходов.

Кроме того вопросы и ответы не зависят от пользователя который работает в данный момент, то почему используется сессия, а не какой-нить in-process cache?

Кстати, почему не использовано HTTP кеширование?

Здравствуйте, gandjustas, Вы писали:

G>Используя сессию вы значительно уменьшаете scalability своего приложения. Это касается даже не кластеризации, когда приложение разворачивается более чем на одном компе, а банального shared хостинга. С увеличением числа пользователей объем хранимых сессий постоянно растет и вы рискуете вылететь за ограничения, что потребует от вас больших расходов.
G>Кроме того вопросы и ответы не зависят от пользователя который работает в данный момент, то почему используется сессия, а не какой-нить in-process cache?

Потому что не до конца продумал архитектуру. Есть набор классов данных (допустим вопросы и ответы), к каждому вопросу привязано несколько ответов. следуя принципу SRP (если я его правильно понимаю), в классах содержатся только те данные, которые соответствуют классу. Соотв. в класс Вопрос я уже не могу положить коллекцию из ответов, которые ему соответствуют, поэтому связь этих объектов должна быть куда-то вынесена. Куда вынесена и как с ней работать пока непонятно.. (.NET 2.0) Какие есть идеи?

G>Кстати, почему не использовано HTTP кеширование?

потому что не открыл для себя ещё этот термин

Здравствуйте, Cyberax, Вы писали:


S>>Ее можно эмулировать на SQL без особых проблем. Тем не менее, SQL достаточно сильно отличается от "классической" РА, и именно потому, что "инженерные" соображения оказались важнее, чем 100% соответствие.
C>Он очень к ней близок.

Да задачи разные, о чём тут спорить? В SQL я не могу указать как именно мне получить результат, я лишь могу указать, что я хочу получить. В большинстве случаев декларативный запрос гораздо короче (для того его и разрабатывали), но некоторые простые операции из РА в SQL выглядят монстрообразно.