Смысл в следующем:
В Бухгалтерии 8 договора контрагентов являются справочником. При этом каждый элемент справочника получается абсолютно уникальным (т.е. нигде повторно не используется). Теряется смысл справочника.
Я говорю, что логичнее было бы сделать договора документом, который писал бы движения в регистр сведений, из которого, в последствии, с помощью механизма виртуальных таблиц, можно было бы отбирать данные гораздо быстрее чем из подчиненного справочника.
Мой товарищ-оппонент, в свою очередь, говорит, что отбор из справочника и регистра по скорости ничем отличаться не будет, поскольку виртуальные таблицы это просто индексы и на уровне sql регистры ничем от справочников не отличаются. Так ли это? )

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

ппц, договора

(71) а как тогда быть с теми ВТ, что создаю я сам в пакетных запросах?

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

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

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

Если делать регистр и документ:
Во первых по структуре регистра придется добавить измерения контрагент и договор-документ - уже 2 поля индексе для таблицы, вместо одного + может еще что то надо будет добавить.
Если делаем документ и регистр то во первых данные будут дублироваться - заполняем рекизиты документа и проводим все в регистр, что уже как бы говорит о нарушении логики(в противном случае если двигать не все,  то в запросах придется кое где присодинять 2 таблицы - документы и регистры что еще более утормозить работу)

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

касаемо быстроты, ну это не суть важно

ТС жжет просто ацки. Складывается впечатление, что он специально прикидывается.

(77) Да не, если упростить вопрос до "что быстрее, выборка из РС или из справочника", отбросив муть про документы - в принципе, нормально, бгг :)

(78) Я и об этом в том числе. Вы с автором вообще ничего про базы данных не слышали? Прямо не верится.

(71) у вас всё перепуталось в голове) - рекомендую проштудировать Проф.разработку, там все по полочкам разложено, имхо на форуме вы ток запутаетесь - либо будете спорить до последнего;
ответ на (0) дан - внимательно перечитайте посты PR из этой ветки)

(79) Понеслась... Любители выглядеть гуру многозначительно, с оттенкой снобизма через губу бросают: "Вы ничего в этом не смыслите" - и гордо удаляются, не удосуживаясь даже попытаться аргументировать свое высокомерие.

Проектированием БД я занимался задолго до того, как пришел в 1С. Возможно, некоторые механизмы взаимодействия 1С и СУБД для меня не до конца знакомы, т.к. необходимости вникать не было. Будьте добры, уважаемый мегагуру, объясните несчастным дилетантам-новичкам, почему я неправ, утверждая, что на уровне MS SQL виртуальная таблица СрезПоследних в 1С является всего лишь подзапросом (даже не view-шкой)?

+(81) Наверное, скульный профайлер тоже спроектирован дилетантами, т.к. упорно выдает именно структуру из вложенных запросов при обращении к 1Совской виртуальной таблице.

виртуальные таблицы надо использовать там где надо, не вижу где здесь их использовать

(70)+(82) жду запрос, который получается на стороне SQL Server, при обращении к виртуальной таблице срезпоследних регистра сведений.

(51) Этот справочник появился когда неким людям надоело сопоставлять физ. лицо и приказ о приеме на работу.

(84) Почему это я должен сейчас тратить свое время, запускать скуль и лезть в профайлер, когда Вы мне утверждаете, что я неправ, при том, что первым свои доводы привел именно я? Жду аргументированного опровержения.

(86) Твою фразу из (61) можно без потери смысла (точнее, без приобретения оного) представить как
"который одинаково правильно спроектировал и самолет, и справочник, то самолет будет быстрее за счет использования крыльев"

(79) Про гуру это да... ) Тоже обратил внимание, что любят тут отвечать в стиле "я бог, знал 1С до рождения, а кругом насрано" )

(86) да оставайтесь невеждой. мне то что.

пример

РегистрСведений.КурсыВалют.СрезПоследних(&НаДату, Валюта В (&СписокВалют))

разворачивается в (примерно):

ВЫБРАТЬ
   КурсыВалют.Период,
   КурсыВалют.Валюта,
   КурсыВалют.Курс,
   КурсыВалют.Кратность
ИЗ
   (ВЫБРАТЬ
       КурсыВалют.Валюта КАК Валюта,
       МАКСИМУМ(КурсыВалют.Период) КАК Период
   ИЗ
       РегистрСведений.КурсыВалют КАК КурсыВалют
   ГДЕ
       КурсыВалют.Валюта В(&СписокВалют)
       И КурсыВалют.Период <= &НаДату
   
   СГРУППИРОВАТЬ ПО
       КурсыВалют.Валюта) КАК ВложенныйЗапрос
       ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрСведений.КурсыВалют КАК КурсыВалют
       ПО ВложенныйЗапрос.Валюта = КурсыВалют.Валюта
           И ВложенныйЗапрос.Период = КурсыВалют.Период

сильно не пинайте

(81) (82) И что? Тебе сказали: там джойн (соединение), джойн тормозит. Ты зачем-то стал спорить. Раз умеешь пользоваться профайлером, так посмотри в него.
Попутно замечу, настоящему проектировщику БД в профайлер смотреть в данном случае без надобности. Он и так догадается, что... там джойн и этот джойн тормозит.

(90) хорошо, не буду

(90) Это из технологического журнала. Я говорил про SQL.

(93) я идею рассказал на нативных таблицах, че придираешься?

(90) точнее в скуле еще вложенный запрос
ВЫБРАТЬ
   Т1.Период,
   Т1.Валюта,
   Т1.Курс,
   Т1.Кратность
ИЗ (ВЫБРАТЬ
   КурсыВалют.Период,
   КурсыВалют.Валюта,
   КурсыВалют.Курс,
   КурсыВалют.Кратность
ИЗ
   (ВЫБРАТЬ
       КурсыВалют.Валюта КАК Валюта,
       МАКСИМУМ(КурсыВалют.Период) КАК Период
   ИЗ
       РегистрСведений.КурсыВалют КАК КурсыВалют
   ГДЕ
       КурсыВалют.Валюта В(&СписокВалют)
       И КурсыВалют.Период <= &НаДату
   
   СГРУППИРОВАТЬ ПО
       КурсыВалют.Валюта) КАК ВложенныйЗапрос
       ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрСведений.КурсыВалют КАК КурсыВалют
       ПО ВложенныйЗапрос.Валюта = КурсыВалют.Валюта
           И ВложенныйЗапрос.Период = КурсыВалют.Период) КАК Т1

(61) Вообще-то в РС виртуальные таблицы медленнее обычных.

(95) ну понятно что это подзапрос (ну или временная таблица)

(68) Вообще-то это касается только РС. А разработали их в РС для удобства, а не скорости.

(94) а теперь бинго, во что разворачивается периодический РС, подчиненный регистратору?

(4) Тогда одинеснегам из фирмы 1С оторвать надо было 5 раз(с 9го по 14й релизы) за БП 3.0

(98) там где нужно юзать срезы, то виртуальная не медленнее обычной, ну если только не по одной валюте, где можно взять ВЫБРАТЬ ПЕРВЫЕ 1

(90) Впрочем, да, прошу прощения. Сейчас внимательней глянул - видать, не туда смотрел, все правильно, к результату вложенного запроса джойнится. Вопрос снят.

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

(81) Потому что нет никакой виртуальной таблицы в SQL для виртуальных таблиц РС.
Для других регистров есть, для РС нет.

(68) учитывая что РС существует покрывающий индекс на все измерения + период и + регистратор если нужно, получается, что выборка среза последних отработает быстрее чем выборка подобная из справочника.

(99) мммм, имхо по моменту времени регистратора
хотя хз, если период<>дата регистратора, думать надо

(102) нюню. читаем внимательно (64), а потом улыбаемся и машем кто кому хамить начал

(103) что значит фраза "Для других регистров есть, для РС нет"?

(87) ... самолета и автомобиля... - так вернее. В том смысле, что каждый объект для своих целей эффективен.

(106) Не понял юмора. Т.е. просьба объяснений в ответ на "Вам еще читать и читать" - это хамство? Ну вообще...

(88) А ты бы хотел по принципу "Ну, для начала начнем с психологической подготовки к тому, что вы нуб и ничего не знаете. Только не волнуйтесь, это не смертельно."? :))

(105) там еще добавляется один джоин к себе, чтобы выбрать макс регистратор. и только 3им запросом выбираются ресурсы

(108) когда человек с пеной у рта начинает доказывать что он чтото знает, но по факту не знает (ну читай как не до конца знает, либо не туда посмотрел), только и остается посоветовать "читать". потому как когда сам прочитаешь, запомнишь на долго, чем поспоришь и останешься при своем

(110) не регистратор, а момент времени регистратора, имхо

(112) в таблицах нет такого понятия как момент времени, поэтому все банально. 3 соединения. 1 выборка макс периода, 2 выборка макс регистратора, 3 выборка данных

(113) согласен, момент времени это составное понятие

(111) А никто и не собирался с пеной у рта спорить. Почему-то нормальный ответ от Ненавижу 1С не вызвал никакого негатива, но заставил призадуматься и перепроверить свои утверждения.

А снобизм в стиле: "хо-хо, еще один неуч, идите читать" - вызывает раздражение. 1Снику, знаете ли, неплохо бы помимо основных профессиональных навыков уметь еще и с людьми общаться.

(103) Для регистров накопления, бухгалтерии и расчета есть. Что непонятно-то?

+(116) К (107) ессно.

(116) все непонятно, в каком смысле есть? с учетом того, что виртуальные таблицы это подзапросы что для РС, что для РН

(118) итоги хранятся для РН

(119) итоги <> вирт. таблицы, одних итогов недостаточно для построения вирт. таблицы

(120) ну для ВЫБРАТЬ * ИЗ РН.Остатки() достаточно =)

(116) Разве в MS SQL вообще существует понятие "виртуальная таблица"? Или под в данном случае подразумеваются представления и/или курсоры?

(118) Да ты че, правда что ли? :)))

(122) Не существует. В MS SQL это просто обычная таблица. Которая "случайным" образом хранит агрегаты основной таблицы :))

(124) Не хранится она. Формируется каждый раз новая при обращении.

(123)(124) очередной опус?

(125) За счет чего тогда скорость выше, за счет исключительно индексов?

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

(128) придумал, оборотный регистр =)

(129) ага, но обороты за 40 дней смотрим

(128) А расхождения между реальной и виртуальной таблицами видимо происходят из-за того, что SQL хреновенько отрабатывает, так?
И пересчет итогов нужен, чтобы не скучно жить было, да?

(128) Да я как бы в курсе. А остатки на базовые периоды где хранятся? Считаются на лету?

(131) к чему эти вопросы ты задаешь?
скажи лучше как по-твоему хранятся итоги по остаточному регистру

(132) на базовые хранятся в таблице итогов, но таблица итогов<>виртуальная таблица

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

(132) Так таблицы итогов - не виртуальные таблицы, а очень даже реальные.

(131) SQL отрабатывает нормально. за все время расхождения встречал пару раз. херовенько отрабатывает файловая версия, так как не транзакционноустойчива.
а пересчет итогов нужен для успокоения души. в SQL он не нужен.

(133) Ну, вообще-то остатки на каждый месяц хранятся в рассчитанных агрегатах, а на дату считаются как агрегаты + или - движения за период в течение месяца.

(134) Зато виртуальная таблица вполне себе использует таблицу итогов, ага?

(136) Блин, читаем (124).

(138) в таблице итогов хранятся остатки, верно, но таблицу итогов нельзя называть виртуально таблицей Остатки, например ))

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

(137) >>за все время расхождения встречал пару раз.
Количество раз не важно. Важно, что это принципиально возможно.
>>а пересчет итогов нужен для успокоения души. в SQL он не нужен.
LOL

(140) А в (103) тогда что написано? :) Ну да, для РС нет таблиц с промежуточными данными, но при чем тут виртуальные-то?

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

(141) И че? Я такое говорил?

(146) нет, ты говорил (103)

(143) если данные пишутся напрямую, в обход 1с.

(142) Во-первых, когда не использует, то это частный случай. Во-вторых, достаточно во-первых :))

(109) Н-да... Воистину неизлечимый случай нарцисизма.

(144) В (103) написано, что в базе SQL нет вообще никакой таблицы для РС, кроме основной. Тут как раз виртуальная таблица — это результат манипуляций с основной таблицей, присоединенной к себе же.
Вот тут могу ошибаться, может и есть физические таблицы, но вроде нет.
Факт остается фактом, виртуальные таблицы РС работают не быстрее основной.

по-поводу РС - нет там вспомогательных таблиц ибо не нужны - максимум периода по индексированным полям берется мгновенно, суммирование в РН требует сканирования, потому и вспомогательная таблица итогов

З.Ы. хотя нет, я знаю как могла быть устроена вспомогательная таблица для РС

(151) просто ты некорректно выразился, остановимся на этом

(148) Вообще-то SQL не знает ровным счетом ничего о связи основной таблицы и вспомогательных.
Их взаимосвязь управляется 1С'ом.

(150) Оставь свое бесценное мнение при себе, ага? :))

(152) Так я про то же и говорю. Потому и не сделали.

(153) As you wish :))

(0) Я ничего не понял: начали за смысл, а продолжили про скорость и виртуальные таблицы.

По смыслу: договорные условия в регистре это логично. Я так делал в одной самописке - заключается договор, заводится документ, который вносит запись в периодический РС. Потом все допсоглашения вводятся на основании этого договора. Актуальные условия на дату получаются срезом последних.

(158) Так ты про совершенно другое. На условия вряд ли понадобится делать ссылку.

(158) Ага. Это я и имел ввиду.

(160) Ага. Ровно это в (0) и написано, точно :)) Буква в букву :))

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

(162) Тьфу ты. Через документ.

(159) ну да - это зависит от задачи: нужно вести учет в разрезе договоров - тогда справочник, если договора это набор условий тогда регистр. Если и то и другое - надо думать )

(154) я про случаи когда итоги расходились с движениями

(154) но в одной транзакции

(162) Это не более логично и не менее. Справочник - таблица и документ - таблица. У справочника есть ссылка (уникальный ключ) и у документа тоже. В своей конфигурации делай, как хочешь.

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

Ну с цчетом уточнений в исходном споре, хотя как я понял 99 процентов форума поняла ТС так же как ия.всетаки считаю даже если в постановки задачи будет сказано что данные договора меняются то логично всеравно введения справочника догворов, а не документа как Договора, и регистров в которые двигаются из формы договора руками или "Заключение договора", "Изменение условий договора" и т.п.

имел ввиду или документами "Заключение договора", "Изменение условий договора" и т.п.