Предположим какую-нить сущность, например, справочник "Контрагенты".
И какую-нить связанную с ним сущность, например, список категорий бизнеса, к которым относится контрагент или произвольный список дополнительных реквизитов.
Вопрос, как вы считаете, где лучше это хранить и почему?

(0) РС. Можно гибчее оперировать кластерным индексом.

А вообще - похер. Всегда можно перейти на РС, если прижем.

(1) Так под табличную часть же тоже отдельная таблица отводится?

(3) Отводится.

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


сколько же в нашей отрасли рисовальщиков формочек со стажем 10 лет. На браных по комсомольскому наборы франчайзи в 90-х
всех , кто не боится компьютера.

Кого волнуют эти академические вопросы?
Берите пример с разработчиков типовых информаций - они вообще ср*ать хотели на всё.

(3) писец. ты вообще 1сник?

(5) Расшифруй свой поток мыслей.

сабж подымается с завидной регулярностью раз в год

(8)
не припомню , что бы мы с Вами переходили на "ты".

(10) избитый приём. есть чонить новое?

До пятницы ещё два часа, а уже цирк!

(12) МихаилМ опять веселит нас.
(10) Тут со всеми на ты.

РС -- единица уникальности -- все измерения + период + регистратор
ТЧ -- единица уникальности -- ссылка на док + номер строки

да причём тут единица уникальности

(5) Не надо мяу, я прекрасно знаю ответ на заданный в сабже вопрос :))

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

вопрос-то в целях

(6) Это не академические вопросы.

(16) ну какие такие вещи

(7) Хи хи.
я говорю, какая хрен разница, какие индексы, раз и то и то хранится в отдельной таблице?

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

(14) Мы говорим про сущности, где идет прямое подчинение ссылке.

(19) Какая разница?

(23) ну с таким же успехом можно перевести табличную часть Товары документа ЗаказПокупателя в РС

какая разница ёпт?!

(21) Почти про это я и говорил в (16).
Я, правда, больше имел в виду чтение объекта потом в каких-либо операциях.

(24) Занятная мысль, кстати.
Аргументируешь, почему нет?

вообще нахрена изобрели ТЧ

ТЧ живёт вместе с родителем

родитель и ТЧ одно и то же целое - при редактировании
поэтому Товары это РС )))

(0) На мой взгляд - смотря что хранить - если немного нужного - то ТЧ, если много (в т.ч. по объему) ненужного то РС.

С точки зрения "рядового" программера-кодера 1С удобнее когда в ТЧ объекта все засунуто

С регистрами сведений это когда одни(похожие) данные привязаны к разным объектам

(32)+ к разным "видам" объектов

ТЧ = живёт с родителем, блокировка, целокупный экзистанс
РС = живёт отдельно, не блокировка, строковый экзистанс

это не учитывая интерфейсных приблуд

Я предлагаю вообще не использовать ничего, кроме регистров сведений и справочников. Все прекрасно на них работает!

Если учитывать (26) - то все зависит от алгоритма, который вычитанные объекты крутит.

(36) +100500

(36) Бери глубже - семерошный Штрих-М кассир 1.9.0.х вообще на одних справочниках был)))
З.Ы.: И даже работал.

я предлагаю использовать тупо объект Таблица

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

(0) Перезаписывать весь объект чтобы подправить только его табличную часть - неохота, лучше уж набор. (21) +1.

(0) Но для ленивых может быть лучше...

(41) это Вам прямая дорога в ораклоиды...

(0)
Если данных для конкретного объекта/контрагента немного и они меняются редко, то лучше ТЧ, с ней проще работать в формах.
Иначе - РС.
Для большинства случаев я лично использую РС.

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

(0) Еще можно создать ДопСправочник, создать в исходном объекте (скажем, документ ЗаказПокупателя) реквизит типа СправочникСсылка.ДопСправочник (связь 1 к 1). В этом справочнике хранить дополнительные поля (реквизиты) и записывать их в определенные моменты (возможно, не перезаписывая основной объект). Очень может выручить в некоторых случаях.

ЗЫ. Где вариант "Другое"?

(46) мда когда уже у нас такие "хозяева рабов" в нашей деревне будут? а то больше 50 никак не хотят платить и это A-шкам (редкие S-ки не учитываем)

Не, просто таблица не прокатит, тяжко эмулировать объектную сущность, объектные блокировки. А вот справочники и регистры сведений вполне катят.

(16) Значит не уверен, раз спрашиваешь.

А вообще, похоже на обсуждение сферического коня в вакууме.
Какая-то сущность. Формируй точные задачи с указанием как будет та или иная сущность использоваться.

... и формочка такая - сверху список из элементов справочника. Снизу динамический список из регистра сведений.
Хо-хо.

С табличной частью в коде обращаться приятнее, меньше лишних строчек. На производительность начихать, пока система не упрется в недостаточную оптимизацию (вам производительности не хватает? Может тогда лучше вообще отказаться от 1С?)

№ 3
Все зависит от поставленной задачи :)

(0) Список сущностей - РС, Список произвольных - ПВХ.

Хотя если самописка или типовая которая никогда не будет обновляться - можно список  как ТЧ.

3. РС + ПВХ.

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

Кто-нибудь помнит, почему в новых типовых (УТ 11, ЗУП 3.0, ERP 2.0) свойства объектов стали хранить в табличной части самого объекта, а не в РС?

(56) свойства объектов так и хранятся в РС, в табличной части хранятся реквизиты...

(36) Я прочитал эту ветку и прозрел!!

(36) Включая остатки товаров на складах без регистра накопления?

(46) Ты не поддержал беседу, а так, ляпнул что-то невпопад

(47) Причем здесь документ?
Именно по этой причине не сделал "Свой вариант", чтобы не писали всякую хрень.

офф...
PR ты чего про поезду на рязанку ничего не написал?

(62) А что писать-то? Съездил, бюджет и задачу выяснил, готовлю предложение.

(2) единственное отличие РС от ТЗ или просто справочника это то что у РС составной индекс, все, если тебе нужно будет получать данные по составному "ключу" тогда РС, если нет это как сам хочешь, исходи из юзабилити

(64) Бреееед

Права у РС лучше по RLS разруливаются
При поднятии объекта ПолучитьОбъект() все строки ТЧ считываются автоматом, в РС - нет

(66) Ради второго я ветку и завел, как уже говорил :))

(36) наши спецы работают только на справочниках - и всё работает прекрасно - ни каких регистров, проведение документов :)))

не будет тупить и меньше влияет на // работы, когда в контрагенты будет кто-то другой заносить еще какие-то данные.

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

Короче вопрос дурацкий

+(66) кроме того РС проверяет уникальность набора измерений автоматом, в ТЧ надо самому проверять уникальность

(70) Я вообще-то привел вполне конкретные примеры, а не сферического коня в вакууме.

Короче, замечание дурацкое.

Если расширить мысль в (71), то разница только в удобстве использования в том или ином случае.

(72) в этом примере нет ни чего конкретного.
хотел еще подъежнуть про красную приталенную куртку, но потом передумал

(73) Ну то есть неважно, например, где хранить приложенные к контрагенту файлы, в контрагенте в табличной части сделать реквизит "ФайлДвоичныеДанные" или в регистр сведений это вынести?

(74) Про то, что не подъежнул про курточку — это молодец. Показал, что чуть взрослее, чем те, кто считает, что здесь есть над чем уписаться.

А про пример согласене, что есть неопределенность некая.
Но тем не менее, многие вещи вполне себе определены.
Например то, что в данных ТЧ не будут храниться большие объемы данных типа приложенных файлов.
А, с другой стороны, хрен его знает, что может быть в допреквизитах. И сколько их.

ты троллоло, Рома. где в (0) про файлы?

если мы стандартный абстрактный пример, то засунь в жопу файлы. Мы их не обсуждаем, т.к. они - конкретика. Если мы за конкретику, то задавай точный вопрос, получишь точный ответ.

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

(77) В (0) как раз про отсутствие файлов.
Где в моих примерах файлы?
А значит понятно, что появляется теоретическая возможность хранить в ТЧ.
Были бы файлы — однозначно не в ТЧ.

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

(79) Я это узнал уже давно.
Так что про судьбу не в кассу :))
А недавно подумал, что можно на эту тему ветку создать, потому что даже по результатам этой ветки сомневаюсь, что каждый первый знает про это.

(0) Архитектура должна быть простой .  Табличная часть .

(81) При получении объекта будет тянуть эти данные.

(79) Во, видишь (83), как народ в большинстве рассуждает? :))

(85)  Так Р-7 тоже по принципу топора проектировалась. Т.к. он простой и значит надежность 99,9.

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

(79) в последних релизах не грузятся.

преждевременная оптимизация большое зло. Сам кнут говорил

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

(40) + 100 :)