С переодическими и подчиненными регистратору все ясно. Мне не понятно, когда имеет смысл применять регистр вместо подчиненного справочника.
У Волшебника в книге "Разработка ...8.0" глава 8 вообще начинается с примера, Измерение: Спр.ФизЛица, Ресурс: Перечисление.РаботаетНеРаботает. Почему предлагается создать регистр, а не создается реквизит у того же справочника?

А как ты историю будешь видеть? Когда работал, когда нет. Есть ведь люди - неделю работает - неделю пьёт...

Перефразирую вопрос. Не понятно, когда применять НЕпериодический регистр сведений. Чем он лучше подчиненного справочника?

Задание прям с сертификации. Предлогается вести учет по FIFO LIFO с возможностью переключения лишь раз в год. Экзаменатор сразу же проверил как реализован этот переключатель. Я сделал на непериодическом регистре сведений. это его удовлетворило. И ни строчки кода.

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

для (4) метод "УстановитьРеквизитСправочника" в 7.7 (в 8-ке, наверняка, есть то-то подобное), поэтому пример не тот. приведи, плз, нужный пример, иначе не могу понять твой ответ.

(5) Скажу короче: делать на справочниках то, что можно делать на регистрах, НЕЛЬЗЯ. Это связано с необходимостью согласовывать доки и (движения регистров), когда правят доки. Так вот, регистр при этом исправляется сам, а в справочнике для этого нужно писать большой объем достаточно "криворукого" кода.

.                                                                                                       .                                                                  
"V8. Есть вопросы по целесообразности применения."
                                                                                               

АкакиеНаку вопросы. Пока нет целесообразности применения вообще.

(2) Он не лучше, он другой. Для каждой задачи - свое решение. Есть статья на ИТС что-то типа "Выбор прикладных объектов для решения определенных задач", там есть пара отличий табличной части, подчиненного справочника и регистра сведений. В моих раздаточных материалах для Мастер-класса была спецтабличка по этим трем понятиям.

(3) Неверно. Регистр сведений должен быть периодическим.

(4) Регистры сведений бывают неподчиненные регистратору, т.е. без привязки к документам.

(5) Подобного в 8.0 нет, потому что нет периодических реквизитов справочников.

(6) Верно.

(6,9)  неверно. на справочниках МОЖНО сделать тоже самое, что и на регистрах... И справочник будет правиться якобы сам (естественнно, с помощью кода)...

Но - получение итогов будет далеко не оптимальным по времени... Это да...
Но если сделать некриворукими руками не-"криворукий" код - то работать будет.

(10) Неверно. На текстовых файлах МОЖНО делать то же самое, что и на справочниках. И текстовый файл будет правиться якобы сам (естественнно, с помощью кода)... и т.д.

Опять таки неверно... К тому же передергивание
Справочник позволяет сэмулировать регистр штатными методами...
Но - медленно

(12) В принципе все можно хранить в строковой константе неограниченной длины.

(4) >Так что я их хочу в 7-ке (нужны достаточно часто), а их там и нет...
А вот почитай статью из "Коллективного разума":
http://1c.proclub.ru/modules/kb/article.php?storyid=30

(9) >(4) Регистры сведений бывают неподчиненные регистратору, т.е. без привязки к документам.

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

(14) Выдержка из статьи: "Ресурс (в терминах v8) соответсвует РесурсуСведений (реквизит V7), даее псевдоРесурс"

Я правильно понимаю, что автор статьи предлагает забить на "геометрический" рост таблиц остатков? На сертификации это же вроде бы заворачивают? (минус 2 балла)?

Что такое "геометрический" рост?

(17) Ну это как гомерический хохот...
Короче, когда регистр остатков не выводится в 0, а регистрируются только приращения остатков (без их уменьшения).

Про рост понятно... И сразу было понятно... При чем тут "геометрический"? Почему не линейный или экспоненциальный?

(19) Движения + каждый месяц в таблицу остатков добавляются записи остатков за прошлые месяцы.
Первый месяц: 1(дв)+1(ост)     2
Второй месяц: 1(дв)+1+1(ост)   3
Третий месяц: 1(дв)+1+1+1(ост) 4
И т.д.
Ой, действительно линейный (я был не прав)... Ну все равно это "как снежный ком", т.е. ситуация неприемлемая.

(15) сразу вспоминается ЗначенияСвойствОбъектов из УТ... на фига тут документ? >;))

(21) Ну, для порядка... С периодическими константами/реквизитами вроде бы в этом основной гемор: юзера наколбасят, сначала документами, потом ручками, а потом поди разгребай за ними. Я бы запретил все подобные вещи, и разрешил только строго документами...

(22) наколбасят... а ты им меню "Операции" не давай...

(23) Через обработку и наколбасят, которая константы выставляет
на указанную дату. Дату, конечно же, указывать забывают, а 1С это проглатывает (ставит по умолчанию текущую). С реквизитами спр - то же самое.
Имхо надо запрещать правки период. реквизитов, не привязанные к документам.
А в типовой 1С они как раз разрешены (специально, наверное...). :-)

(9) Мдя.. конечноже я напутал.. Естественно периодический (периодичностью год) :)

(6)
Вот пример:
В типовой УТ персональные настройки пользователя хранятся в регистре сведений НастройкиПользователей. При этом разработчики "выеживались" с формой элемента справочника пользователи.
На франчайзинговой конфе справшивал как лучше в такой ситуации - ответ: как проще обращаться к данным, так и делай.
Так проще обратиться к реквизитам.
ИМХО
Регистры сведений (ну кроме случая с периодикой) имеет смысл делать при необходимости отслеживания уникальности по "ключу" (комбинации измерений).

(26) Я тоже довыёживался...

"Я правильно понимаю, что автор статьи предлагает забить на "геометрический" рост таблиц остатков? На сертификации это же вроде бы заворачивают? (минус 2 балла)? "
(romix) Ты ничего не понял из статьи. Там кстати есть и пример использования.
Можешь сам убедиться что нет никакого геометрического роста базы и вообще нет
понятия закрытия региста V7 если у тебя в регистре содержаться Только реквизиты.
Минус два бала за сертификацию за такой метод - ну мне это знаешь как-то не грозит.
Не давай неправильных советов другим. Регистр сведений v7 работает и его функциональность практически идентична рег сведений на v8.
Кстати с помощью регистров сведений v7( v8 ) временые зависимости от двух и более велечин.
(all) всем кто работает с v7 советую разобраться и понять статью из (14).

(28) Скачал, посмотрел структуру регистра. Ну я это часто использую для выборки (все в Измерениях). А как там сделать получение последних состояний? ОбратныйПорядок()+ВыбратьДвижения()?

(29) Ну я тебя точно не понимаю. Переведи с русского на русский :)

(+29) У меня была задача: есть электромеханики, есть лифты (2400, возможно будет больше). Документом происходит закрепление определенных лифтов за определенным механиком. Для расчета з/п механиков надо получить выборку: все лифты по всем механикам на 1 число указанного месяца. Так вот, через периодические реквизиты это решается. А через такую схему - я долго думал, но не понял, как сделать оптимально (чтобы не строить гигантскую таблицу в памяти).

(31) Не совсем понятно что ты хранишь в этом "регистре"
если база dbf тогда
Рег.Обратныйпорядок(1);
Цикл по сотрудникам
Рег.УстановитьФильтр(Сотрудник);
цикл по лифтам
Рег.УстановитьФильтр(Лифт)
   Рег.ВыбратьДвижения(, Дата1);
   Пока Рег1.ПолучитьДвижение() = 1
     здесь твой результат;
     Прервать;
  КонецЦикла; // по регистру
КонецЦикла; // по лифтам
КонецЦикла; // по сотрудникам
если база sql можно написать прямой запрос
select и top(1)

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

(33) Коры никакой нет. Ты же отбираешь отфильтрованные движения.
Фильтр делает только один шаг по индексу для каждой пары сотрудник,лифт.

(34) А вроде бы верно! Я попробую и так и так сделать, и результат напишу...