1cV8: справочник или периодический регистр сведений? #124183

Пытаемся с коллегами разобраться, что предпочтительнее использовать Справочник или Периодический регистр сведений. Положили одни и те же данные в Справочник и Регистр, сделали Запросы к ним и через SQLProfiler посмотрели sql-скрипты. Скрипты идентичны абсолютно, разница лишь в том, что при создании Регистра созданы индексы по измерениям, датам и т.п. А по справочникам индексы созданы только для Наименования, Кода и Родителя. Поскольку рекомендуется использовать запросы,а не объектную модель при работе с регистром, то возникает вопрос почему бы не использовать в подавляющем большинстве случаев вместо регистра справочник.

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

Даже если нет разницы в производительности, это разные объектыНапример на запись регистра не может быть ссылок, иногда это + иногда -, от этого во многом зависит что выбрать справочник или регистр.Кроме того писать в запросе СрезПоследних намного удобнее чем писать отдельный подзапрос, так запрос удобнее читать и понимать.

Насколько мы поняли, разработчикам 1С на учебных курсах вбивают в голову, что регистры рулят, а справочники нет. И быстрее они и идеологически более правильно их использовать. Насчет гемороя... да он будет, но при этом снимаются ограничения накладываемые использованием регистра.Рассмотрим пример: есть ответственный квартиросьемщик и есть члены семьи. Нужно отслеживать время проживания в квартире членов семьи. Можно создать ПРС с измерением Квартиросъемщик и ресурс ЧленСемьи. При этом необходим некий третий параметр (измерение) для того чтоб занести нескольких членов семьи. Минус такого решения так же в том, что нужно еще отслеживать состояние живет или нет (измерением или ресурсом). В справочнике же достаточно четырех полей: квартиросъемщик, член, датаЗаселения и датаВыселения

В регистре сведений тоже достаточно 3 полейИзмерения:Квартиросъемщик ЧленСемьиРесурсЖивет- булевоЯ начинаю сомневаться в правильности ваших замеров

Немного поразмыслив пришел к выводу что вы предлагаете полнейший изврат.1.ЧленСемьи вселился создаем запись в справочнике с открытой датой выселения2.Выселился НАХОДИМ ЭТОТ ЭЛЕМЕНТ СПРАВОЧНИКА и записываем туда дату выселения3.Он снова вселился ..... создаем новый элемент4.При этом надо отслеживать чтобы периоды элементов не пересекались, иначе будет удвоение срока проживания5.ужас, руки за такое надо отрывать

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

если бы это была 7.7. В которой не было SQL запросов такое решение может быть и имело бы право на жизнь. Ну или если у вас где-нибудь 10^9 запиейи член может вселиться только 1 раз.

1) Чем плоха открытая дата выселения.. Живет себе человек, никому немешает.2) Найти запись проблема?3) Или может нужны большие усилия для создания новой записи в справочнике?4) А в регистре типа пересечения периодов не будет. Что мешает сначала занести две записи подряд "вселился" и только потом "выехал"

Ладно не будем пиписьками меряться.Удачи вам в автоматизайии родного ЖКХ.

Глупости.

Так ведь в "семерке" запросы ваще были неживые и вопрос то задан именно применительно к восьмой версии.

Всё как это не прискорбно малоубедительно. Объяснить прелесть регистра видать не дано...

Более внимательное изучение предназначения справочников и регистров сведений неминуемо приведет Вас к отказу от подобного подхода. Вам , возможно, сложно изучить возможности нового объекта. Очень помогают виртуальные таблицы регистра. Если продолжить Вашу мысль, то не проще ли в таблицы Экселя собрать списочек?

Откуда у вас такая уверенность, что виртуальные таблицы создаются при адресном запросе к регистру (т.е. получение конкретной записи регистра). Так написали разработчики 1с? Не поленитесь посмотрите sql-запросы.Запрос к справочнику:ехес sp_ехесutesql N'SELECT_Reference13_Q_000_T_001._Description f_1FROM_Reference13 _Reference13_Q_000_T_001 WITH(NOLOCK)WHEREЗапрос к регистру:ехес sp_ехесutesql N'SELECT_InfoReg1996_Q_000_T_001._Fld1999 f_1FROM_InfoReg1996 _InfoReg1996_Q_000_T_001 WITH(NOLOCK)WHERE

Ну не надо так расстраиваться.:0)Делайте так как Вы поняли. ... или не делайте.Практика лучшее доказательство

Есть две методики - ввод в справочники/регистры при помощи документов и вручную.И только если у Вас с помощью документов (что в принципе правильно), то нужно выбирать только регистр, т.к. при перепроведении по справочникам старые действия автоматом НЕ ОТМЕНЯЮТСЯ.

to 16 не правда ваша дяденька, если вы хотите делать отмену каких либо действий в справочниках ( если они заменяют регистр сведений ), то просто надо использовать ПередУдалением (BeforeDelete) или ОбработкаУдаленияПроведения (UndoPosting) или ОбработкаПроведения (Posting) и вычищать или перезаполнять не нужные справочники.

16 писал: "...старые действия автоматом НЕ ОТМЕНЯЮТСЯ"ключевое словл автоматом.

Ну у меня то опыта побольше...Подумайте над словом "Перепроведение".Это значит был проведен док с элементом1, а потом зашли, изменили на элемент2 и перепровели.Спрашивается почему не вызывается ОбработкаУдаленияПроведения ? Ошибка двух платформ? (в 7.7 тоже самое)

Подумайте над пунктом ОбработкаПроведения (Posting) если вы храните в справочнике какую либо периодическую информацию ( например Цену и документ который это сделал в табличной части ) и хотите , что бы она при перепроведенеии вашего документа изменялась, то программист с опытом сначала сделает отбор по табличной части справочника с фильтром по документу вытрет все ссылки ,а только потом запишет новую информацию.

Для "перепроведения" в упоминается об "ОбработкаПроведения", кроме того можно запретить менять элементы без отмены проведенияВ 7.7 есть УстановитьРеквизитСправочника

При чем тут изменение цены, если я говорю об изменении самого элемента справочника. Как Вы его проведение будете отменять, если при перепроведении не вызывается ОбработкаУдаленияПроведения ? Можно сначала отменить проведение, а потом провести, но это уже ручная работа. Я имел ввиду обычные реквизиты (без галочки периодический)

какое проведение справочника ? Вы все одну кучу начали сваливать см

Не проведение справочника, а изменение реквизита документа типа справочник в проведенном документе. Вы непонимаете потому что этого никогда не делали. А Ваше предложение в не сработает, т.к. в ОбработкеПроведения у Вас реквизит документа типа справочник уже будет установлен в элемент2 и у Вас неполучится "вытереть" все ссылки в элементе1, так как Вы не будете знать что до элемента1 был элемент2, если, конечно, не заниматься сохранением всех реквизитов документа до перепроведения - но это будет очень КРИВО! Готов ли автор к этому? Нет, конечно. Он лучше будет вручную редактировать справочники, чем делать это с помощью документов!Поэтому моя основная мысль осталась (для тех кто это понимает):Если изменение вручную - то справочники вполне подойдут, а также ПРС.Если изменение документами, то ТОЛЬКО РЕГИСТРЫ!

Вот написал за 5 минут хранение изменений справочника , документами. Два справочника один подчинен другому у подчиненного два реквизита реквизита Цена и Регистратор. При проведении ищем ссылки удаляем их и записываем новое значение цены.Процедура ОбработкаПроведения(Отказ, Режим)