Имя: Пароль:
1C
1С v8
Почему контактную информацию в типовых решили хранить в табличной части?
,
0 Sam1C
 
23.04.21
12:01
Посмотрел видео собеседования https://youtu.be/_oY0YJ24E7Q?t=806, там на мой взгляд несложный вопрос, чем отличается хранения данных в табличной части справочника и регистра сведений в случаи если данных нужно хранить по конкретному элементу справочника. Ответ очевиден в ключе данных, в ТЧ ключ будет всегда один Ссылка, в регистре можно задать свой ключ по средствам измерений.
Вопрос, почему контактную информацию в типовых решили хранить в табличной части, а не как раньше в регистре сведений? чем это обосновывается?

Была такая проблема при обмене УТ11 с Бух., в УТ КИ хранится в ТЧ, а в Бух. в регистре и вот в УТ был задублирован адрес в одном контрагенте (различались только представления)  соответственно, пришлось делать доп. проверку при загрузке в БУХ., есть уже запись с таким ключом в Наборе или нет, это раз и два это что мы ни как не знаем какая из них более правильная и остается записывать первую!
1 ДенисЧ
 
23.04.21
12:02
Чтобы два фактических адреса можно было ввести.
Как у нас тут умудрились. И обмен падал...
2 Волшебник
 
23.04.21
12:04
Чтобы работал RLS по контрагентам.
3 Sam1C
 
23.04.21
12:11
(2) RLS и на регистр можно установить, тут поддержка уникальности по мне более оправдана следуя заповедям теории баз данных
4 mikecool
 
23.04.21
12:12
блокировки, размеры таблиц, да мало ли что еще
5 Волшебник
 
23.04.21
12:14
Передача контрагентов вместе с контактами между узлами РБД
6 Aleksey
 
23.04.21
12:15
(3) ага особенно в большой базе ...
7 Sam1C
 
23.04.21
12:17
(4) могу ошибаться, но вроде как блокировки можно устанавливать не только на весь регистр, но и на отдельные записи регистра. А по размеру таблицу, что в ТЧ одна физическая таблица, что в регистре, отличаются только кол-вом индексов
8 Волшебник
 
23.04.21
12:18
(7) может битва за целостность данных? При записи контрагента должна в той же транзакции записываться его контактная информация
9 RomanYS
 
23.04.21
12:19
(5) В РБД как раз по фигу: есть изменения (хоть в РС) - перенеслось.
10 mikecool
 
23.04.21
12:21
общий ответ - 42
11 Sam1C
 
23.04.21
12:22
(8) Согласен это плюс хранения в ТЧ, но пока непонятно перевешивает ли он минус отсутствия уникальности
12 Garykom
 
гуру
23.04.21
12:27
Где лучше хранить свое в дополнительных реквизитах или дополнительных сведениях?
13 RomanYS
 
23.04.21
12:29
(12) ответ в (10)
А так логика понятна: нужно редактировать независимо от объекта - выбираешь сведения
14 Волшебник
 
23.04.21
12:30
(12) в файле, который загружен в отдельно стоящую SQL-базу в BLOB-поле
15 Sam1C
 
23.04.21
12:31
(10) на счет блокировок, при записи элемента справочника заблокируются в ТЧ записи по ключу Ссылка, а в регистре при записи Набора заблокируются записи по установленному отбору поэтому из-за блокировок сомнительно что такое сделали.
16 RomanYS
 
23.04.21
12:31
(11) Почему "минус"? Возможно это главная причина (хотя непонятно что мешало расширить ключ в регистре)
17 Sam1C
 
23.04.21
12:38
А еще если сравнить размер транзакции при записи элемента справочника с кучей реквизитов и таб. частей и одной записью  в регистр. Например, нужно загрузить только контакты придется перезаписывать все элементы справочника при хранении в ТЧ
18 RomanYS
 
23.04.21
12:43
(17) Как правило объектов с контактной информацией не так много (на фоне возможностей современного железа и ПО).
Сейчас в современных типовых конфах уход от нормализации и минимизации объема данных: куча служебных регистров которые пишутся в фоне и т.п.
19 Anton1307
 
23.04.21
12:49
Копирование контрагента вместе с контактными данными.
Сериализация/десериализация
20 DGorgoN
 
23.04.21
13:21
(19) Ну эт бред. 2 дубля будет что ли?
Мне тоже непонятно сиё.
21 LoneBull
 
23.04.21
13:27
(0) Я когда-то давно первый раз увидел - спросил зачем так странно, дубли же и индексов подходящих не будет.
Мне сказали что-то типа - это нам пофигу, зато запись целостная с объектом и права сами работают.
22 Sam1C
 
23.04.21
14:01
(21) Могли бы хотя бы проверку на дубли ПриЗаписи встроить в модуле объекта, так сказать обойти проблему уникальности
23 Жан Пердежон
 
23.04.21
16:28
в (0) ответ ни о чем да еще и неправильный. Самое существенное различие именно в правах доступа: при хранении в одном регистре, чтобы нормально разделить права придётся использовать RLS.
Если в ТЧ - хватит тупо прав на сам справочник.
24 Вафель
 
23.04.21
16:44
Помимо прав доступа ещё можно 2 телефона указать например
25 Serg_1960
 
23.04.21
16:49
У методистов поменялась методика. Печатные формы одно время хранили в документах, потом всё перегнали в обработки, потом стали хранить в отчетах, а теперь хранят и там и тут... не спрашивайте меня "Почему?" может быть универсализация и унификация на них так пагубно действует что ли... не спрашивайте вы меня.
26 Kassern
 
23.04.21
16:49
(24) с помощью костылей в виде/типе можно было так же указать в регистре)
27 Вафель
 
23.04.21
17:16
(26) а версионирование?
Плюсов больше получается
28 Kassern
 
23.04.21
17:19
(27) да никто не спорит
29 Dzenn
 
гуру
23.04.21
17:36
Причины перехода на табличные части в справочниках были следующими:

1 — оптимизация быстродействия
2 — возможность корректного разграничения прав доступа
3 — более логически верная конструкция. Не было никакого обоснования для хранения подобной информации в общем регистре, кроме того, что почесалась левая нога архитектора, впервые взявшего за реализацию учёта контактной информации в ранних конфигурациях — проще говоря, такая реализация изначально была ошибкой.
30 Dzenn
 
гуру
23.04.21
17:48
(29) + действительно сериализация/десериализация и общие обработчики событий
31 Вафель
 
23.04.21
17:59
(29) как раз оптимизация в минус ушла
32 Волшебник
 
23.04.21
18:02
(31) Действительно. Ведь так удобно было получать СрезПоследних по регистру КонтактнаяИнформация... Теперь вот как получить актуальные телефоны?
33 Domovoi
 
23.04.21
18:22
(32)А что регистр контактной инфы был периодическим?
34 Said_We
 
23.04.21
18:30
(0) Как почему. Что бы функцию написать в БСП и объект передавать, а не запросом по всем объектам к которым адрес можно привязывать и с составными типами работать. Из-за БСП так сделали - отвязались от типа объекта путем отвязывания от типа данных, но при этом копипаст структуры в каждом объекте - бред. Тогда бы сделали типы данных новые, которые не хранятся сами по себе, но могут назначаться объектам,  но тогда бы это была объектная древовидная БД как КАШЕ :-)
В общем заигрались с БСП.
35 Волшебник
 
23.04.21
18:33
(33) Конечно.
36 RomanYS
 
23.04.21
18:35
(35) Где? В БП2/УТ10/УПП никогда не был периодическим
37 Волшебник
 
23.04.21
18:38
(36) Мир не ограничивается типовыми
38 acanta
 
23.04.21
18:39
Есть вариант с последними релизами брать данные из истории изменений обычного текстового реквизита?
39 RomanYS
 
23.04.21
18:55
(37) но тема вроде как раз про них
40 Ботаник Гарден Меран
 
23.04.21
19:17
На партнерке есть короткий неинтересный ответ: Права доступа.
41 ДедМорроз
 
23.04.21
21:48
Допреквизиты тоже хранятся в т.ч. объекта.
Удобство в том,что ПолучитьОбъект и больше в базу не ногой.
Опять же,то,что не планируется изменять отдельно от изменения объекта нет смысла хранить отдельно.

С правами,как раз можно и регистр через РЛС разделить.
42 Волшебник
 
23.04.21
23:07
(40) Было в (2)
43 Cthulhu
 
24.04.21
02:28
а кстати - да. с переходом на уф и ресурсоемкие перегоны данныз сервер-клиент - получить на клиента пакет информации, обработать и перезнать обратно при набобе - гораздо проще и экономнее при хранении в "статистически значимого" пакета данных, характеризующего сущность, одном объекте.
44 ДедМорроз
 
24.04.21
17:30
Там ещё параллельное использование.
Если все читают или пишут одну таблицу,то на ней могут быть столкновения,особенно,когда в нее пишется новая запись.
45 Конструктор1С
 
24.04.21
18:06
(0) отчасти ради производительности, отчасти ради библиотечности, отчасти ради тяги к костылям. Не все технические решения фирмы 1с проходят нормально, некоторые отличаются нелепостью. Например, в 2007 году мы писали:

Сообщить("Привет мир!);

в 2021 году пишем:

ОбщегоНазначенияКлиентСервер.СообщитьПользователю("Привет мир!");
46 Said_We
 
26.04.21
12:02
(43) "характеризующего сущность, В одном объекте" - адрес не сущность объекта и может отсутствовать. Это же не ИНН организации РФ и не дата рождения ФизЛица и не ФИО. Типов адреса тоже может быть сколько угодно и в разных форматах.

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

Правильно такая задача решается путем ввода специального типа данных, который можно назначать реквизиту объекта, что бы не копипастить структуру. В ООП это класс. В КАШЕ это специальный тип данных, который сам по себе не хранится, а только с объектом. Так как ООП в 1С нет и не будет, скорее всего, то пришло время создавать свои типы данных с методами - почти классы, но не классы.

А то всё рюшечки рисуются и УФ. Тут по возможностям архитектуры, платформы и работы с SQL (хотя бы стандартный SELECT расширить до стандарта оконных функций + стандартные конструкции типа select t1.a1 as a1, (select top 1 t2.a from t2 as t2) as a2 from b as t1) и т.д.. В общем непочатый край нормальной работы, а не рюшечек.
Компьютеры — это как велосипед. Только для нашего сознания. Стив Джобс