Last1Cmen[quot автор]А как может вторая табличная часть документа отличаться по периодам от самого документа?

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

И что? Напоминаю у меня по подобной схеме работал механизм хранения цен с их периодами.

Last1Cmen
а по-поводу разнесения по таблицам так спор о падении скорости я думаю не уместен... другое дело дело насколько это критично... думаю не сильно

Наверное спор и не уместен - только скорость записи в справочник медленней особо не будет - т.к. документ надо в 3 таблицы записать!!!!

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

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

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

Last1CmenавторЕще раз юзаем профайлер хоть вы и говорите, что у вас на него алергия!

так и есть

попробуйте "перезалить" ТЧ с проведением документа и "удалить\записать" соответствующее количество элементов справочника без прямого обращения к БД... только средствами 1це

Зачем пробывать я сотни раз пробывал - не делает 1С UPDATE, а делает сначала DELETE, а потом INSERT.

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

о точ, что ТЧ достаточно перезаполнить неверен в корне т.к. сначала надо перезаполнить, а потом перезаписать документ. А в момент перезаписи 1С вам и сделает сначала DELETE, а потом INSERT.
Поэтому если в табличной части документа к которому хотим пределать вторую табличную часть в виде справочника, будет более 500 строк - для справочника в котором храним вторую таб. часть, что запись, что удаление будут практически моментальными. Проверьте и убедитесь сами.

Last1Cmen или модифицировать (процедура поиска тоже тормозом будет)...
Обратите внимание, что реквизиты справочника индесированные - поэтому поиск с использованием ВыбратьЭлементыПоРеквизиту() будет не медленней, чем НайтиПоКоду.
И я вас уверяю прямые запросы не обгоняют - ВыбратьЭлементыПоРеквизиту().
Попробуйте сами.

Last1Cmenда тоже самое будет т.к. без выноса в отдельные реквизиты справочника каждого из доп. элементов (а в особенности если обращаться к дате документа и через неё уже к таблицам документа основания) будет нечто аналогичное по количеству объединений и те же самые обращения к таблице журнала док-тов и т.д.
Ну и зачем тогда муйдохаться с документами - если и не быстрее и не удобней?

Last1CmenавторИ я вас уверяю прямые запросы не обгоняют - ВыбратьЭлементыПоРеквизиту()

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

Опять же а как по вашему 8.1 хранит данные табличных частях? Да и таже 7.7 хранит данные табличной части документа одного вида в одной таблице и индекс там по IDDOC.
И проблем у меня с джоинами никогда не было, джоин с подзапросом TOP1 с сортировкой по полю с датой.
Ну если и говорим про штатные средства - а что 1С вам документ соединять в Запросе 1С будет быстрее чем справочник? Это с чего бы это? Справочник хранится в таких же таблицах, как и Табличная часть документа, для табличной части документа используется индекс IDDOC+LINE_NO_,
для справочника буде индекс по ДокументуОснованию т.е. фактически по IDDOC. И где же здесь для документа быстрее? За счет чего?
При этом для табличной части документа доп. индексов иметь нельзя в отличии от справочника.
Попробуйте проиндексируйте тоже поле ОтчетКоммисионера - не получиться. А для справочника можно. Уже только поэтому можно строить более быстрые выборки.

Last1Cmenvitkhv, вы предложили использовать для отбора данные из документа родителя (дата, подотчетник) а это те же обращения к таблицам шапок и ТЧ документа + к таблице журнала документа (вернее в обратном порядке) что аналогично тому если бы мы сразу работали с ними без справочника вот и всё

Хорошо вопрос к вам как будет быстрее?

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

SELECT ДокОснование.SP31,СправочникТабличнаяЧастьПени.SP67 AS ДокументПени
FROM DT45 ДокОснование
LEFT JOIN SC22 СправочникТабличнаяЧастьПени ON СправочникТабличнаяЧастьПени.SP345 = ДокОснование.IDDOC AND ДокОснование.SP67 = СправочникТабличнаяЧастьПени.SP12

По методу с документом запрос будет выглядеть так:

SELECT ДокОснование.SP31,аблЧастьДокТабличнаяЧастьПени.SP53 AS ДокументПени
FROM DT45 ДокОснование
LEFT JOIN DH55 ДокТабличнаяЧастьПени ON ДокТабличнаяЧастьПени.SP15 = ДокументОснование.IDDOC
LEFT JOIN DT55 ТаблЧастьДокТабличнаяЧастьПени ON ДокТабличнаяЧастьПени.IDDOC = ДокТабличнаяЧастьПени.IDDOC = ТаблЧастьДокТабличнаяЧастьПени.IDDOC
AND ДокОснование.SP67 = ТаблЧастьДокТабличнаяЧастьПени.SP53

И 1С штатными средствами надо точно такие же соединения сделать.
А теперь скажите при какой организации второй табличной части будет быстрее при том, что поле ТаблЧастьДокТабличнаяЧастьПени.SP53 не индексированно и штатно без отключения верификации ты его не проиндексируеш? И скажите где соединений меньше?

HSVvitkhv,
Хотя если реквизит имеет ссылку на документ, то Сортировка отсутствует
Отбор там надо ставить, какая может быть сортировка для ID документа? Документ в терминах 1С сортируется по дате, в поле нет даты поэтому нет и сортировки.

Last1Cmenvitkhv, ага - сферический конь у тя получился :)

добавь выборку по подотчетнику за период (сумму пени за отчетный период в любом случае надо будет выдавать "на гора") и попробуй обойтись без таблицы журнала док-тов и таблицы шапок документов данного вида которые уже будешь по джойнить с справочниками ;)


Медленней со справочниками точно не будет, даже если прийдется дополнительно лезть в другую таблицу для получения даты документа, ведь при использовании вашего метода прийдется всегда лезть в шапку документа, чтоб узнать Док. основание.
Ведь в методе со справочником всех остальных выборок где без развертки по периодам можно обойтись без лазиния в какие либо другие таблицы. Можете еще в справочник реквизит датаДок вставить тогда вообще никуда лазить помимо справочника не прийдется.
При этом в справочнике можно проиндексировать ЛЮБОЕ поле, попробуйте это сделать для Таблицы документа.......
Вот вам и сферичиский конь в пальто ;)

Егоров Александр
Реквизиты справочника хотя бы позволяют построить "произвольные" индексы, в отличии от реквизитов документов, что ускорит выборку "нештатными" средствами.
Почему не штатными.
Еще раз повторюсь - метод справочника ВыбратьЭлементыПоРеквизиту() работает очень быстро... прямыми запросами мне его обогнать не удалось.