|
Почему контактную информацию в типовых решили хранить в табличной части? | ☑ | ||
---|---|---|---|---|
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) и т.д.. В общем непочатый край нормальной работы, а не рюшечек. |
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |