Last1Cmenда можно всё что угодно вставить но речь то о штатных механизмах

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

MicMicВы еще подеритесь, горячие финские парни.
:)

1. По моему не принципиально справочником или документом.
В разных ситуациях и то и другое может оказаться медленным.
Но как правило медленнее - подчиненный документ, т.к. цепочка получаается - журн, црдок, ДШ, ДТ.
Лично я, как правило, предпочитаю справочники - различные производственные документы с несколькими табличными частями и делать несколько подчиненных доков, а если одна таб часть подчинена другной, а это в свою очередь, третьей и т.д., то совсем весело получается.
ИМХО.

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

MicMic
2. При двух табличных частях, можно все затолкать и в ТЧ документа. А на экранную форму выводить в двух таблицах значений.

Можно и так - даже помню где то пример был в Клубе профессионалов 1С - но не удобно мне показалось.

MicMic
3. Чего делать не стоит, это хранение в текстовых полях. Контроль целостности теряется на уровнре системы, да иглюки бывают когда всяки "значения в строку внутр туда сюда таскаешь".
Тем более организовывать хранение в различных внешних файлах или таблицах sql (видел как то такое извращение).
Но в принципе в простых случаях можно и так, в строку. Например, список сотрудников, проводивших просчет по конкретной инвентарной ведомости, можно в строку загнать. Информация по сути нужна только для печати ведомости, ну и немного на время инвентаризации, а потом она никого не интересует. Да и инвентаризации если проводятся 1-2 раза в год ...

ИМХО. Вообще текстовые поля как ссылки использовать - плохой тон.

MicMic
4.
vitkhv,
Ну так что по вашем делает 1С когда любой объект перезаписывает?
Она его удаляет!
1С слова Update вообще не знает.
Еще раз юзаем профайлер хоть вы и говорите, что у вас на него алергия!

Если говорить о движениях регистра, то вы правы.
Документы и элементы справочника при перезаписи именно апдейтит, а не удаляет, потом создает заново.


И даже после перезаполнения табличной части документа с использованием ЗагрузитьТабличнуюЧасть()? Не думал, что 1С такая молодец! Нет 7.7 под рукой посмотреть не могу. Вроде когда тригеры писал FOR UPDATE никогда не использовал.

vitkhv,
5. А вообще, не понимаю зачем пени и их расчет в документ оплата отчетов комиссионера.
Делайте отдельный документ начисления пени. И все.
Как правило пени начисляют на некоторые просроченные суммы. Чаще всего начисления идут зависимо от дней просрочки и соответсвенно привязаны к документу создавшему задолженность.
Пени - увеличение задолженности и на них, могут быть начислены еще пени и т.д. (в зависимости от договора).

Не проще расчет/начисление пени просто напросто отдельно делать?

ИМХО.
Здесь вы правы, но иногда некоторые полностью прогибаются под пользователей и делают абсолютно все что те говорят. Иногда еще есть постановщики задач - которые так задачи ставят - хотя вроде и профи.

MicMicLast1Cmenвот попробуйте перепровести месяц с 2мя док-тами (основным и подчинённым) и с 1 док-том плюс удалением/созданием новых элементов справочника ему принадлежащего штатно и увидите разницу

я её видел и справочники использовал только если их немного будет (порядка десятка) и модификации они подлежать вряд-ли будут

Причем тут удалить/создать элементы справочника при проведении?!

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

У меня именно при проведении использовалось для замены периодических реквизитов в частности механизм хранения цен полность был заменен данным справочником. Т.е. по сути эмуляция регистра сведений.
Проводилось точно не медленней чем УстановитьРеквизитСправочника().
И обмены по УРИБУ стали гораздо быстрее проходить, чем с обновлением _1SCONST.

MicMicLast1CmenавторВ справочнике хранить табличные части человек собирается

он (она) там результаты расчета будет хранить (суммы пени)... соответственно они меняться будут в зависимости от модификации ТЧ главного док-та или изменения историии взаиморасчетных док-тов

если бы оно один раз вбилось и потом не трогалось то бога ради справочники так справочники

Т.е. при проведении меняеются данные в самом документе?
- сорри не увидел, где это говорится.
- за такую реализацию, извините, нужно по попке ремешочком. А то еще при проведении одного документа, меняют данные в другом, т это вообще ппц. Концов не сыщешь.

Как я понимаю в данном случае при проведении данные менятся не будут. Во время ввода будут забиваться данные по пеням. Или я не прав?

HSVДобрый день!
Снова прошу помощи. Вернее идеи, как лучше организовать.
Есть документ "ОплатаОтчетовКомиссионера". В табличной части находятся отчеты комиссионера, которые оплачиваются. Так вот, в этом документе происходит еще расчет пени. Одна из колонок документа имеет кнопку выбора, при нажатии на которую происходит расчет пени. Расчет пени надо показать на закладке "Пени" этого же документа. Т.е. получается, что на каждую строку табличной части документа приходится еще таблица с расчетом пени. Через какой объект это лучше организовать. Хотела использовать метод ЗначениеВСтрокуВнутр(), но табличная часть документа не может иметь неограниченную длину.

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

MicMicvitkhv
MicMic
4.
vitkhv,
Ну так что по вашем делает 1С когда любой объект перезаписывает?
Она его удаляет!
1С слова Update вообще не знает.
Еще раз юзаем профайлер хоть вы и говорите, что у вас на него алергия!

Если говорить о движениях регистра, то вы правы.
Документы и элементы справочника при перезаписи именно апдейтит, а не удаляет, потом создает заново.


И даже после перезаполнения табличной части документа с использованием ЗагрузитьТабличнуюЧасть()? Не думал, что 1С такая молодец! Нет 7.7 под рукой посмотреть не могу. Вроде когда тригеры писал FOR UPDATE никогда не использовал.



Не передергивайте.
Вы удалили строки из документа, и записали новые. Все правильно - 1с за вами повторила.
Устраивать эвристический анализ что, где когда, что можно и не удалять (т.к. фактически не изменилось), а что надо, встраивая в систему псевдоинтелект? Ню, ню. В какой системе вы такое видели?
У 77 много проблем, но лишнее выдумывать зачем.
:)

MicMic, видимо вам надо прочитать это пост от начала и до конца и в частности предмет нашего спора с Last1Cmen, и аргументы в споре. В предлагаю вам прочитать аргументацию моего аппонента где он использует метод ЗагрузитьТабличнуюЧасть() как аргумет того, что это будет быстрей чем удалить и записать справочник, либо вообще его не трогать если он не изменился.

Last1Cmenавторсорри не увидел, где это говорится.

прямо и не говориться но если результат записи в справочниках(документе) зависит от чего-либо (в данном случае от ТЧ главного документа) то он будет меняться и это аксиома как и то что все будут работать задним числом и ошибаться и вследствии чего будут перепроводиться документы с исходными данными (а пеня по-любому от срока будет зависеть а с позициями документов ошибок больше всего)

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

Да ну.А вы когда в последний раз - типовую УПП смотрели? Например в случае когда договор с признаком по документам расчета? Там как раз и появляется доп. ТЧ куда по ФИФО ввставляются документы по которым оплата проведенна. И при проведении задним число данные в этой ТЧ никак не меняются.

Last1Cmenавторкак аргумет того, что это будет быстрей чем удалить и записать справочник

да... загрузить сотню строк и записать документ (не провести а записать) будет быстрее чем удалить и создать сотню элементов

Тем более на сотне строк разницы особой не будет. Да и на 500 тоже.