Привет всем, во внешней системе, реализовано решение, которое необходимо в какой то мере повторить. Данные там хранятся не как в 1с, вид 2 на скрине, а как на виде 1. https://ibb.co/ifOSUy  
для своего пользователя  они выводят данные как в 1с,

вопрос, стоит ли организовывать такую структуру в 1с? какие риски при такой организации данных могут возникнуть?

"для своего пользователя  они выводят данные как в 1с, "  имею ввиду в пользовательском режиме, а структура  хранения как доп реквизиты в 1с

(0) А если свойства добавятся?

(2) Возможно и такое, добавлять реквизит наверное придется

(0) Сегодня вроде не пятница же.

(0) Дык РС "Значения свойств объекта", не?

(5) как я знаю, вопрос в том стоит ли ?

(6) стОит или не стОит - решать тебе, я к тому, что такой объект в 1С уже сто лет как есть и про преимущества и недостатки можно легко найти информацию

(6) Теория баз данных настаивает на варианте 1. Хотя в определенных случаях допускает денормализацию до варианта 2.

+ (8) https://habr.com/post/64524/

(8) "Теория", меня больше интересует реалии 1с

(10) Вы о чем это пишете сейчас? О каких таких "реалиях"?

(11) Работа с такой структурой данных (варианте 1), когда все типовые сделаны с вариантом 2 (исключая доп реквизиты). Построение запросов и т.д.

(12) "когда все типовые сделаны с вариантом 2" Вы не понимаете о чем пишите.
1. Контактная информация.
2. Договора контрагентов.
3. Данный физ лиц.
...
и прочая и прочая и прочая... Все нормализовано. Хотя бы до первой формы.

(13) Хорошо, по Вашему таблица варианта 1, это какая нормальная форма?, и есть ли объект в типовых конфигурациях с такой структурой данных (доп. реквизиты не в счет)

(14) С какой такой структурой? Я же вам написал - "договора контрагентов". Для примера.

+ (15) Я надеюсь на таком примере будет понятна разница между
Контрагент1, Договор1, Договор2, ... ДоговорN
и
Контрагент1, Договор1
Контрагент1, Договор2
Контрагент1, Договор3
...
Контрагент1, ДоговорN

а вообще почитай уже https://habr.com/post/64524/ Там в стиле "для больших и маленьких. на селе и в городе". Ну в смысле все просто расписано. Зачем и когда.

(15) с структурой как в варианте 1

Если не типовая конфа. то добавление реквизитов предопчтительнее, чем свойств

(12) Все типовые сделаны по разным "вариантам". И по первому, и по второму. Причем я не врубаюсь вообще что вы хотите. Вопрос в чем? Чтобы Вам прочитали краткую лекцию по теории нормализации баз данных?

+ (17) Ну тогда - еще раз. Третий. Но это уже последний.

Договора контрагентов вынесены в отдельную таблицу. Средствами платформы установлена связь по владельцу. И таблица договоров выглядит ровно по варианту 1. Есть ведущее поле "Владелец" и кортеж реквизитов конкретного договора. Причем записей с одинаковым значением поля "Владелец" может быть несколько.

В таблице контрагентов нет полей "Договор1", "Договор2"...

(20) ты описываешь подчиненные таблицы, а это реквизиты - совсем другое

(21) Слава богу

Свойства они нужны, чтоб в конфигуратор не лезть.
А так в них никакой пользы нет

(21) а таблицы реквизитов отличаются от таблиц подчиненных объекта?

+(24) *подчиненных объектов

(24) (25) подчиненные объекты однотипные, а реквизиты они нет

(21) "подчиненные таблицы" - понятие чисто 1С. Я пытаюсь описать принцип.
По своей сути - таблицы регистров сведений тоже "подчиненные таблицы". Точно так же как и табличные части и подчиненные справочники.
Вспомните историю с данными "контактная информация". В одно время это был подчиненный справочник. Потом регистр сведений. Потом табличная часть.
Вся разница - это наличие платформенных методов для работы с ними.

(26) Далеко не факт :)

(27)Отношение "один к многим" - если тебе не нравится термин подчиенные таблицы.
А тут речь совсем про другое

(27) КИ хранится в таблице потомучто не известен заранее споск всех видов КИ

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

(30) Никто не мешает их хранить в РС или подчиненном справочнике.

(16) в Вашем примере:

Ссылка      | ДоговорКонтрагента
------------|-----------
Контрагент1,| Договор1
Контрагент1,| Договор2

Это как раз таки вариант 2.



если как в варианте 1 то было бы

Ссылка      | Свойство           | значение
------------|--------------------|----------
Контрагент1,| ДоговорКонтрагента | Договор1
Контрагент1,| ДоговорКонтрагента | Договор2

Вот скажите мне теперь , Вариант 1 Это разве нормализованная таблица?

(30) насколько я понимаю, в исходной задаче (0) - тоже

(33) а чем у тебя первый и второй вариант отличаются? Полем "Свойство"?

+ (32) И одна из причин следовать теории баз данных то - что состав реквизитов у разный ведущих объектов неизвестен. См (3).
Кроме того у разных "ведущих" может оказаться разное количество реквизитов. Придется заготовку делать с запасом.

(32) ТЧ, Поддчиненный справочник или РС - это технологически одно и тоже

+(35) первый и второй вариант - не из (0), а из (33)

Но если у разных объектов - разное количество реквизитов (типо характеристик: у одних длина у других вес), то лучше через свойства

(38) в первом варианте можно добавлять новую строку(бзе добавления полей):

Контрагент1  | ТипКонтрагента  |   Конкурент

а чтобы это сделать во втором варианте нужно добавить новое поле "ТипКонтрагента"

(36) вы говорили что в типовых есть примеры как в 1 варианте, я так и не нашел тот пример что (16), я уже в (33) написал

(41) не так написал:

вы говорили что в типовых есть примеры как в 1 варианте, я так и не нашел такой пример.

А тот что в (16), я уже в (33) написал

(40) так я про что и говорю:
один раз добавить "свойство" - и все, и это превращается в вариант со свойствами. Разовое изменение - не делает эти схемы принципально разными.

вот когда ты используешь схему Контрагент1|Договор1|Договор2 , тогда КАЖДЫЙ раз когда тебе понадобится новое свойство, ты будешь добавлять новое поле.

а в (33) - разница только в одном-единственном РАЗОВОМ изменении

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

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

(45)
Во всех типовых повсеместно используется и Вид 1, и Вид 2

(46) А ты можешь мне привести пример Вид 1?

(47)
В этой ветке уже приводили. Самое явное - Контактная информация, Значения доп сведений объектов и т.п.

(0) Не понимаю, к чему сюда теорию БД приплели, нормализацию, и т.д. У случая 1 плюс - простота в обслуживании и масштабируемость, у случая 2 - быстродействие. Все, выбирай, что тебе важнее.

(49) взял и всю систему поломал)

(0) Свойства нужны, если:
1) справочник номенклатуры сильно "разношерстный", а у разных групп номенклатуры сильно разные реквизиты.
2) высоконагруженная база в режиме 24/7, а реквизиты часто добавляются.

Иначе - конечно реквизиты удобнее.

Вариант 1 плох только одним:

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

Именно поэтому в типовых в объектах существуют реквизиты.

(49) Меня это и поставило в тупик, я все капаю про нормализацию базы, и не нахожу нужного.

(53) Я просто не программировал на других языках, неужели в не в 1с таблицы выглядят как то по-другому?