Только что проскочила тема. В той ветке не удалось поспорить по-существу, поэтому открываю свою.
Итак. Лично я - за справочник. Думаю, если бы разработчики платформы имели представление о составном уникальном ключе, им не пришлось бы плодить лишнюю сущность.
Ваше мнение.

Я за дирижабль

(0) они имеют представление, именно так и есть в РС

(0) За базАр за "лишнюю сущность" неплохобы ответить.
Всмысле чем это она лишняя?

Вопрос за то имеют / не имеют представление пока опустим.

(3) ниче не понял
пред.ветку не видел :)

отреж себе пальцы на ногах, зачем тебе лишние сущности, да ещё и десяток...

(2) Я имел ввиду, что при наличии справочника с возможностью задания составного уникального ключа делает регистры сведений не нужными.

надо было разделить понятие периодического и неперодического регистра нафиг
а так с РН - остатки и обороты

Нет пометки удаление, есть измерение ведущее. Индексы для измерений.
Нет родителей, кода, наименования,владельца и прочей лабуды.
Они для разных целей.

(4) Аналогично. Прочитал только старт этой ветки.

+(6) наличие ... делает

(2) так кто против то? периодичность эмулировать можно, вся конфигурация на справочниках

(6) а нафиг всем справочникам составной ключ?

(6) Такая возможность у вас есть уже сейчас. Называется подчиненный справочник.

Уникальный составной ключ? Так вот жеШ он : УИДВладельца + УИДЗаписи.

(12) почему всем? ))

(13) феерический бред

(15) Сами вы вот это вот.

(0)

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

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

(17) То есть ты за справочник?

Имхо полезная вещь, но по сравнению с РН оборотным, лучше бы сюда добавили итоги для периодического регистра

(18) Стоп... стоп...
Перейдем к ваше логике. Все (основные) объекты базы данных суть таблички. Достаточно одного объекта с миллионом методов? Так было бы лучше?

(11) Про всю конфигурацию разговор не идет. Есть смысл разделять сущности: справочники, документы, регистры.
Вопрос ставится так. Зачем еще одна сущность - регистр сведений?

(19) т.е. это разные сущности

(21) Лучше - когда есть сущности необходимые: справочники, документы, регистры. И нет сущностей лишних (регистр сведений).

(18) По сути они и есть. В них не прописаны родители владельцы код или наименование. Регистр хорош еще тем, что его легко удалить, в отличие от справочника, т.к. на него нет ссылок.

(0) почитай для начала книжки из комплекта поставки, может что то прояснится в голове )

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

(27) хранятся данные по-разному

25 + Вообщето есть у него уникальный _SimpleKey  но вот для чего он, не имею понятия.

(0) Реализуй срез последних на справочнике м.б. тогда ты меня убедишь :)

(24) Ещераз. Базар о "лишних сущностях" требует обоснования.

(22) ЧистоКанкретнаяИМХА. Одна из причин появления РС - проблемы обмена (в РБД, с другими системами ...)

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

Такое себе "вертикальное расщепление" из теории БД.

+(31) Конечно тоже самое можно реализовать на справочниках. Будут называться "Справочники дополнительных реквизитов".
Но вопрос ведь не в названии?

А то что в регистрах может быть больше одного измерения автор слышал?

+(33) Вкупе с тем что у справочников есть уникальная ссылка и с некоторой штукой, которая называется нормализация БД ?

(0) мало какая ерп может похвастаться такое сущностью как регистры, мои знакомые профи-ораклоиды в чистых СУБД на оракле "рожают" эмуляции подобных таблиц самомтоятельно, т.е. ручками и сетуют "у тебя мол разработчики уже прогнулись - бери и пользуйся"

вывод: предлагаю добабавить в голосовалку пункт
4. тс - наркоман

(32) а если к такому справочнику добавить периодность записей(измерение период), то это уже будет мамонт

(0) садись - два. регистр от справочника отличают не индексы, а отсутствие и наличие ссылки

Ибо нефиг

(0) Автор ветки вы работали с 1с77???
У вас в справочниках были периодические реквизиты?
У вас были тормоза со справочниками в 1с77?

Классная вещь.

вот тут шаблон периодических сведений
http://www.sql.ru/forum/actualthread.aspx?tid=620607

(37) Регистр от справочника отличается предназначением.
В регистре сведений "ссылка" есть, просто она составная.

(42) ссылка - это то, на что можно сослаться.
Ты можешь сослаться на запись регистра сведений и поместить ссылку в другой объект?

И вообще.

Ты правда уверен, что для всех случаев лишнее поле ГУИД (которое есть ссылка справочника) ну просто необходимо?

Ты действительно считаешь, что единственный объект, дающий связь "многое ко многим"  , является лишним?

(42) Ты понимаешь словосочетание ссылочная целосность?
Нормализация БД?
Это не ссылка, а измерение для поиска. Удаление данной записи не ведет к краху ссылочной целосности. Понятие ведущее для измерения позволяет каскадно удалять записи вместе с удалением ведущего измерения

(31) Справочник с миллионом реквизитов - плохой справочник.

Вот и в книге знаний говорится, что регистр сведений по своей сути справочник. Полностью согласен.

измерения рс - поля первичного ключа.

такчто можно считать  рс справочник  с составныс ПК
для которого нужно самостоятельно написать метод
автонумерации.


справочник - прикладная сущность,  которую можно идентифицировать по простому ПК. + второй Уникалный Ключ - номер;

если для всех сущностей требовались бы составные ключи
не было бы типа модификатора IDENTITY increment

(47) Почему сразу у всех? У кого-то составной ключ, у кого-то простой. И зачем автоинкремент? Лично меня коды бесят. Зачем их сделали по-умолчанию, да еще так, что без бубна не уберешь? 95 % - код не нужен.

Еще раз.

СПРАВОЧНИК.

Обязательные свойства справочника:
- Имеет один ГУИД
- Можно на него ссылаться (размещая его ГУИД)

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

РЕГИСТР СВЕДЕНИЙ.

- Не имеет собственного ГУИДа.
- На него нельзя ссылаться.
- Имеет составной первичный уникальный ключ, зависимый от набора измерений.

Дополнительные свойства:
- Может иметь измерения (значения, формирующие составной уникальный ключ)
- Все данные по нему могут быть зависимы от наличия ведущих измерений
- Может устанавливаться регистратором
- Может иметь периодичность (поле период + ВТ для среза)
- Может иметь ресурсы (= реквизиты, значения которых можно получить по составному ключу)
- Может иметь реквизиты (= реквизиты, значения которых нельзя получить по составному ключу)
- Не может иметь табличные части


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

Автор просто привык в клюшках эмулировать явно недостающие для функционала регистры справочниками. Почти в каждой 7шной конфе есть куча "виртуальных" справочников, которые никуда не выбираются, а чисто хранят привязки.

(49+) кроме того, неясна суть предложения об объединении.

Внести справочник с составным ГУИД-ом? и что с ним делать.
Варианта 2: а) на него можно ссылаться б) на него нельзя ссылаться.

Вариант (б) точно соответствует текущему регистру. Что за справочник, на который нельзя ссылаться? При чем тут будут код и наименование? К чему крепить таб. часть?

Рассмотрим вариант (а). ОК, сделали такой объект. В документе сослались на составной ГУИД (к примеру, из 3х измерений). После чего меняем в записи одно измерение. Составной ключ изменился. Что должно произойти со всеми ссылками?

Короче говоря, вся тема - бред.

(51) Хорошо. Поставлю вопрос по-другому.
Есть справочники, документы и регистры.
К какой группе вы отнесете регистры сведений?

составной FK как-то не кошерно, имхо

(48) ну сделай длину 0 ему и все

(52) Есть уши, носы и пальцы. К какой группы вы отнесете ж*пу?

(55) ж*па - это базовый класс для потомков: уши, нос, пальцы, т.к. согласно идеологии опп все растет из ж.. т.е. из базового класса.

двоешник ты

(48) Сразу видно человека который не часто делает длину кода равной 0.
Не все, ты про бубен забыл.

(55) Это ты хорошо сказанул.
Только аналогия по-справедливости должна быть такой:
"Есть уши, носы и пальцы. К какой группы вы отнесете ПАЛЬЦЫ ж*пы?"

код справочника - это встроенный реквизит ПОЛЬЗОВАТЕЛЬСКОЙ идентификации записи таблицы БД. Да можно их убрать и в случае пользовтельской идентификации заводить свой собственный, но код - это системный реквизит и по логике запросы к системному более быстрые, чем к своему

(58) ты со своей веткой

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

(60) Ужас-ужас

(59) Код не нужен в 95% справочников.

(62) ну ты понимаешь, что мнение и статистика дилетантов всегда не объективны, да

(0) давай уже обсудим альтернативную платформу? я серьезно

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

(64) регистры - это утрированная модель многомерного пространтства, где наполнителем оного является не материя, а информация(данные), что тут обсуждать - теорию многомерных пространств сейчас учат на 1-м курсе вышке, кто не учил, тот проходит по сообщению (65)

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

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

(64) Я так далеко не думал.
В принципе, меня нынешняя 1С вполне устраивает.
Пусть она несколько аляповата, но базовые принципы - вполне здоровые. Два уровня абстракции. Хороший баланс между физическим и логическим уровнем.
Интересно, что тебе не нравится?

(69) невозможность архитектурного расширения базовых вещей, та же иерархия справочников или (68)

(69) ну вот теперь принялся вылизывать попу 1С - это, между прочим, правильный шаг на пути професонализма и очень полезный навык)

(71) Лучше дай еще определение регистрам. Они у тебя такие интересные получаются.

(70) альтернативную иерархию для таблицы справочника сейчас можно сваятть В

дсиске
запросе
СКД(только не так как писала та женщина - гуру СКД)

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

(73) СКД хороша на отчетах, для логики проведения тоже ее юзать?
кстати, сделай условие В ИЕРАРХИИ в ЛЕВОМ СОЕДИНЕНИИ

(74) ту (73) последнее предложение

(75) отож

(70) А как сделать так, чтобы в результате не получилась платформа, с которой только ее автор и будет работать?

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

(78) Сожалеешь о чем?

(79) я уже ответил на этот вопрос в (60)

зануды и критиканы, всё я спать, братцы ))

(80) Сожалеешь, что эта ветка появилась? И поэтому сюда пишешь? В том числе, юморески про регистры?