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

Так в том то и вопрос, что в сложных решениях состоящих из лапшекода с временными таблицами, запросами в строках (то есть без возможностей рефакторинга / анализа), кучей дырявых пересекающихся абстракций, ручными блокировками (абсолютно нетестирующимися), ручной оптимизацией запросов, разделением сервера и клиент и так далее (все остальное что есть в статье, а это еще далеко не все) нахрена эта армия нужна? Максимум сбоку отчетик подкинуть? Потому как лично я бы постремался что-то менять в этом коде. А то будет, как президент Беларуси говорил, "взялся за яйца молоко пропало".

L_argoТак в том то и вопрос, что в сложных решениях состоящих из лапшекода...Такое есть во всех системах. И чо ?

Первый шаг к решению проблемы - понимание того что она существует.

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

The Dim!Nitro_Junkieпропущено...


Предметная часть интересует. А то там часть комментариев в стиле: да все не так, автор не разобрался и все такое. И мне реально интересно, где все-таки "автор не разобрался".

Попробую, как смогу, объяснить, на примере тезиса о "Неэффективное получение данных объектов".

Автор статьи пишет: В 1С объект читается всегда целиком, в том числе с табличными частями, но не более того (без каких либо связанных данных).

Что не так.

Начнем с терминов и определений - что такое Объект?

1С даёт такое определение этого термина.


Например, Организация - как объект, в терминах 1С - это совокупность ИНН, ОГРН... вид организационно-правовой формы... в конце концов наименования этой самой организации... идентификатор (УИД/GUID). С течением времени эти значения не меняются.

Связанные данные - например - учётная политика и ответственные лица (директор, гл.бухгалтер... ). Эти данные зависят от периода времени. Тут связь один ко многим. Иными словами, одному объекту соответствует несколько наборов данных из "связанных данных".

Например, учётная политика меняется каждый год. Могут меняться директора, гл.бух. Причём, эти данные актуальны для своего интервала времени.

Например, мы формируем некую отчетную форму - баланс - за прошлый год и позапрошлый год. В прошлом году у нас был другой директор и другая учетная политика. Организация - та же. А вот наборы данных о отвественных лицах и учётной политики, для каждого года свои.


Такая же ситуация и с документами. Есть Объект - Документ - например поступление товаров и услуг. В состав объекта входят реквизиты - Организация, Контрагент, Склад, табличная часть с товарами: номенклатура, цена, количество сумма... (упрощенно)

А есть проводки/движения этого документа. Которые не входят в состав этого объекта, но связаны с ним. Эти данные - данные движений - вынесены в отдельные таблицы, имеющие агрегаты и виртуальные таблицы.

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

Эти виртуальные-агрегированные таблицы позволяют существенно повысить скорость получения данных. Например, виртуальная таблица с остатками, для регистра товаров на складе, содержит данные в разрезе дата/склад/номенклатура ну и собственно количество товара на остатке. Индекс - дата.
Для получения остатка нужно выполнить только выборку.

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

Это если кратко...

Отсюда вопрос: в каком виде должен быть представлен объект, например, Организация, сразу со связанными данными?
Отсюда вывод, мой, возможно, субъективный: автор не понимает сути того, что он назвал объектом.

Опять же вопрос: а какова должна быть глубина данных объекта?

Теперь о достаточности и не достаточности данных.
1С даёт два механизма чтения данных:
1. Через объект. Объект читается из информационной базы сразу весь.
2. Запрос на языке запросов 1С. Возвращается набор записей, только с теми полями, которые были указаны в выборке (допустимы JION и UNION). Т.е. сразу, за одно чтение, получить нужные данные.

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

Если сделать так:
ДокументОъект.ТаблицаТоваров.Количество(Цена) - то мы сразу получим число, собственно само количество(или цену). Всё хорошо.

А если так:
ДокументОъект.ТаблицаТоваров.Номенклатура - то... что мы получим? В этом реквизите лежит ГУИД объекта. Но, 1С, на уровне платформы, сделает запрос - не явный для нас - и подставит туда объект который сериализует обьект номенклатуры с этим гуидом.

Да, в 1С так делается. И возможности платформы по подстановке, и примеры - патерны! - кода самого вендора... и "низкий порог" в сумме дают ... то, что дают.

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

Вопрос какой способ получить данные самого объекта и "связанных данных" выбирает разработчик. Просто не надо забывать(надо понимать) что данные объекта, содержат данные именно самого объекта, границы объекта. А если надо получить связанные данные, то для этого есть запросы...

Ничего нового.

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

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

vill_agerавторвиртуальная таблица с остатками, для регистра товаров на складе,
содержит данные в разрезе дата/склад/номенклатура ну и собственно
количество товара на остатке. Индекс - дата.
никогда не вникал, как 1с внутри устроена.
Т.е. 10000 товаров * 365 дней дают виртуальную (а на самом деле реальную, но невидимую?)
таблицу на миллионы записей?

Там у них с виртуальными таблицами вообще трындец . Одно вот это чего стоит:

ВЫБРАТЬ
РасходнаяНакладнаяСостав.Номенклатура,
УчетНоменклатурыОстатки.КоличествоОстаток
ИЗ
Документ.РасходнаяНакладная.Состав КАК РасходнаяНакладнаяСостав
ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.УчетНоменклатуры.Остатки(,
Номенклатура В (
ВЫБРАТЬ Номенклатура
ИЗ Документ.РасходнаяНакладная.Состав
ГДЕ Ссылка = &Документ)) КАК УчетНоменклатурыОстатки
ПО УчетНоменклатурыОстатки.Номенклатура = РасходнаяНакладнаяСостав.Номенклатура
ГДЕ
РасходнаяНакладнаяСостав.Ссылка = &Документ И
(УчетНоменклатурыОстатки.КоличествоОстаток < РасходнаяНакладнаяСостав.Количество ИЛИ
УчетНоменклатурыОстатки.КоличествоОстаток ЕСТЬ NULL)

Zmeelov2Nitro_JunkieОдно вот это чего стоит Темен, смешон и непонятен язык 1С для явиста и шарписта. Но кристально прозрачен и может быть даже приятен для постигавших ФоксПро, ABAP, Ассемблеры и машкоды.
Если серьезно - язык запросов 1С - специфический диалект SQL, со вставками платформозависимых расширений. В приведенном вами примере, если не обращать внимание на русский язык, нет ничего ужасного.
Единственная проблема, реально вставшая у меня при переходе на 1С - русская орфография. Теперь приходится внимательно проверять русские тексты - зачастую забываю ставить пробел.

Да причем тут русский язык. Там Predicate push down руками делается. Нахер вот это вот делать:

Номенклатура В (
ВЫБРАТЬ Номенклатура
ИЗ Документ.РасходнаяНакладная.Состав
ГДЕ Ссылка = &Документ)

Это вообще нормальные СУБД и платформы сами делают. А тут все на разработчика перекладывают.