Реквизит справочника - этот же самый справочник.
 

Есть элементарный справочник. Один из его реквизитов имеет тип - этот же справочник. Мне приснилось, или у такой конструкции бывают подводные камни? Я что-то подзабыл :(

(0)>>Мне приснилось, или у такой конструкции бывают подводные камни?
А ты где такое видел?
Вообще сделать такое можно, проблем нет, никто не запрещает, вопрос только ЗАЧЕМ???

Теоретически возможно зацикливание при обработке цепочки элементов по этому реквизиту какой-нибудь рекурсивной функцией.

(2) Это не теоретически, это практически будет, получить самого себя.

(3) Это понятно, но не факт, что это обязательно выйдет боком.

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

(4) Ну тут тогда просто грамотность построения алгоритма

[quote=nordbox;45141965]А ты где такое видел?[/quote]
Например, так организован спр.сотрудники в ЗиКе. Но речь не о нём. Речь О самоделке, где спр.техника содержит и автомобили, и прицепы. Так вот реквизит "прицеп" - это тип спр.техника. Вот думаю, нужно ли развязать эту конструкцию, или меньше гемора будет, если не лезть к нему..

..а вспомнил о ЗиКе, потому что про эту конструкцию рассказывал Сущеня, дескать, она чем-то нехороша. Но поскольку было это 10 лет назад, забыл я, в чём там косяк :(

В ПУБе было, ничего страшного.

[quote=Странный аттрактор;45142258]реквизит "прицеп" - это тип спр.техника. Вот думаю, нужно ли развязать эту конструкцию[/quote] Если разнести авто и прицепы по разным уровням справочника и при выборе реквизита контролировать уровень выбранного, то можно все разрулить, ИМХО.

[quote=Ткачик;45142268]можно все разрулить, ИМХО.[/quote]
ок, прислушался. Оставлю, как есть.

Эх.. До чего же хороша была "семёрка"! Задал вопрос, тут же ответ, проблема решается мгновенно. Ностальгия..

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

[quote=Странный аттрактор;45142326]хороша была "семёрка"! Задал вопрос, тут же ответ, проблема решается мгновенно. Ностальгия..[/quote] Просто тут остались одни динозавры...

[quote=nordbox;45142381] а чем восьмерка то плоха? )))[/quote]
тем, что для решения задач, которые в семёрке решали 1-2 спеца, в 8ке нужен целый коллектив. Трудно себе представить, чтобы на 8ке 1 чел взял и написал полноценную конфу, скажем, по производству. Девиз 8ки - "долго и дорого". Злит.

[quote=Странный аттрактор;45142452]а 8ке 1 чел взял и написал полноценную конфу[/quote]
Чем больше я работаю тем с каждым днем все меньше и меньше программирую :)
Потому, что все уже изобретено, надо только знать где лежит и подобрать.
Я вон для Андроида нетленку сваял, так только от того, что делать нефиг было да и интересно. А в инете уже валом.

Любой иерархический справочник имеет такой реквизит - Родитель.

По моему ничего не будет, хоть все реквизиты делай того же типа, что сам справочник. В 7.7 сам не раз делал, в 8.x для примера у контрагентов есть головные контрагенты. Даже если сам элемент прописать в реквизит и то не видно причин бояться )

Нет никаких камней, ни подводных ни надводных.

делала. но через подчиненный справочник - деталь и ее аналоги

Коллеги, пьянствуете уже?

Таких конструкций полно. Откройте справочник Контрагенты в типовой БП. Там реквизит Головной контрагент имеет тип того же самого справочника Контрагенты.

Мало того, если он не заполнен, туда записывается ссылка на тот же самый записываемый элемент.

видел в 7-ке такое , для того чтобы справочник открывался как документ , то есть имел табличную часть
ЗЫ подводных камней не особенно если рисовать с умыслом
ЗЫ удалять сложновато бывает ))

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

(23)Это в порядке бреда ?) Справочники бывают (да ну !) многоуровневые, и для каждого уровня свой регистр ? Это тянет на нобелевскую премию. Как раз нормальный подход хранить ссылку своего типа. Именно так организуются различные списки, очереди и т.д. Например требуемая последовательность техопераций. В чем конкретно ушербность проектирования ? Должна быть линейной - сказал, как отрезал. А почему не шарообразной ? Есть вообще то такое понятие как нормализация баз данных, все правда про него уже забыли.

23-USSR > не для каждого уровня свой регистр, а список уровней всех справочников в одном общем регистре/справочнике.
справочник - предпочтительнее. т.к. в нём уже можно типовыми средствами задать многоуровневую структуру. просто элементы верхнего уровня будут названиями всех прочих справочников, а уже в каждом таком элементе свои группы и подгруппы и подпод группы. если говорить о родителях.
например. есть справочник Номенклатура с группами "Материалы" и "Товары". Есть справочник "Контрагенты" с группами "Поставщики" и "Покупатели".

Так вот, предполагается создание служебного справочника "РодителиВсехСправочников", в котором создаются группы "Номенклатура" и подгруппы в ней "Материалы" и "Товары", аналогично группа "Контрагенты" и в ней подгруппы "Поставщики" и "Покупатели". Одновременно справочники Контрагенты и Номенклатура делаются одноуровневыми с реквизитом Роодитель содержащим ссылку на справочник РодителиВсехСправочников.

Требуемая последовательность техопераций... ка по мне так это отдельная сущность "ПоследовательностьТехОпераций", которая содержит набор ссылок на сами ТехОперации.

О! Нормализация! И где в ней сказано, в нормализации, что надо хранить в записи ссылку на саму запись или ей подобную? По-моему, там что-то про однотипность сущностей было, не? А группа и элемент справочника, например, Номенклатура - однотипные сущности?

это если по-1Сному, то один общий справочник РодителиВсехСправочников.
а если по-нормальному, то для каждого справочника должен быть свой СправочникРодителей<ИменноЭтогоСправочника>.
технически я не вижу проблем такое организовать на уровне платформы. ибо кроме двух таблиц (элементов и родителей) нужен ещё и объект, который сможет всё это отобразить в форме списка, позволит работать с отборами, подборами, добавлением элементов и групп, изменением подчинённости и т.п.

про неродителей зацикливание и удаление уже писали.

[quote=Зелёный тролль;45174717]О! Нормализация! И где в ней сказано, в нормализации, что надо хранить в записи ссылку на саму запись или ей подобную?[/quote]
а почему бы не хранить?
Не пора ли освежить азы программирования?
Такой объект, как дерево значений (в том или ином виде используемый во всех СУБД) - строится именно на таком принципе. Элемент хранит ссылку на родителя.
Иерархический справочник по сути и есть дерево.

26-Ирли Бёрд > пусть хранит ссылку на родителя. я не возражаю. но это будет ссылка на другой справочник, а не этот же.

26-Ирли Бёрд > дерево значений и нормализация БД - это разные вещи, однако.
С т.з. БД дерево значений - это связь один-ко-многим (вероятно и несколько раз, то есть с большим количеством таблиц, чем две), а не ссылки на эту же таблицу. разве не так?

(22) замечательно будут смотреться иерархические структуры у которых элемент родитель обладает теми же [u]свойствами и [b]поведением[/b][/u] что и подчиненные. Как пример: справочник подразделений.
Подход (22) может быть уместен если родитель используются [b]исключительно[/b] для группировок/отборов

Бред какой-то

(0) Приснилось!!!

(0) В справочнике контрагентов есть реквизит "головной контрагент" и никто ещё не умер)