Имя: Пароль:
1C
1С v8
оптимизация хранения данных
, ,
0 Shark_2000
 
13.10.19
14:16
Всем Добрый день.

Вопрос возможно глупый... но всё же.

Есть справочник у которого более 40 реквизитов, обычных не в табличной части, таких справочников будет около 10 000 - 30 000 тыс, реквизиты будут заполняться не у всех.

С точки зрения скорости работы запросов и т.д. и т.п.

Лучше оставить все реквизиты в одном справочнике или перенести в подчиненные.

Заранее Спасибо!
1 hhhh
 
13.10.19
14:20
(0) там сейчас все справочники такие, в чем вопрос?
2 NorthWind
 
13.10.19
14:26
Ну, 30000 тыс это, видимо, опечатка. Но даже 30 тыс справочников по 40 реквизитов? Моделью каких данных это является, даже интересно...
3 Консультант Баранов
 
13.10.19
14:26
(0) > реквизиты будут заполняться не у всех.

Больше похоже на свойства объектов.

> Лучше оставить все реквизиты в одном справочнике или перенести в подчиненные.

А еще можно перенести в ТЧ справочника.
4 Консультант Баранов
 
13.10.19
14:28
(2) > Моделью каких данных это является, даже интересно...

Например номенклатуры.

Для одной номенклатуры нужны: "размер штанов, размер рубашки, размер головы", для другой: "длина, ширина, диаметр, марка стали" и т.п.
5 Лефмихалыч
 
13.10.19
14:39
(0) в программировании не существует единственно правильных ответов для всех случаев. Без конкретики разговора не получится.
6 Shark_2000
 
13.10.19
14:40
(2) это будет подсистема ЖКХ, и 30 тыс. это даже не предел. Справочник помещения и лицевые счета.
7 Garykom
 
гуру
13.10.19
14:40
(0) С точки зрения работы лучше оставить один реквизит, куда записывать все прочие в виде JSON.
А для выборок/поиска использовать хеширование.
8 Shark_2000
 
13.10.19
14:40
(3) Свойства объектов не подходят... кто их будет заполнять в ручную...
9 Shark_2000
 
13.10.19
14:41
(7) подробнее....
10 Garykom
 
гуру
13.10.19
14:41
(6) Подразумевал вероятно под 30к кол-во элементов справочника а не разных видов справочников каждый со своими 40 реквизитами и хз сколько элементов.
11 Garykom
 
гуру
13.10.19
14:41
(9) Подробнее изучают в ВУЗах или самостоятельно.
12 Shark_2000
 
13.10.19
14:42
(10) Да
13 Shark_2000
 
13.10.19
14:43
(11) Это не новость... Хоть где искать???
14 Garykom
 
гуру
13.10.19
14:43
(12) Если это 8-ка то сделай ТЧ разные по "заполняться не у всех".
Банально и просто.
15 Garykom
 
гуру
13.10.19
14:45
(14)+ В смысле ТЧ в которой будет всего одна строка с набором реквизитов-полей или не будет если для данного элемента не нужна.
16 Shark_2000
 
13.10.19
14:46
17 Shark_2000
 
13.10.19
14:48
данные делятся на группы, кадастровые данные, ГИС ЖКХ, Регл. учет, и прочее.
18 hhhh
 
13.10.19
14:51
(2) 30000 элементов похоже
19 H A D G E H O G s
 
13.10.19
14:52
Забей и воткни все в реквизиты.
20 H A D G E H O G s
 
13.10.19
14:52
Потомки тебе спасибо скажут.
21 rphosts
 
13.10.19
15:49
(0) ээээ, может не "таких справочников будет около 10 000 - 30 000 тыс" а элементов в справочнике?
(19) +1. Ну может только что-то типа строка неограниченной длины перевести в подчинённые, а так 40 =- не много. У меня была жесть где 200+ элементов... единственная проблема - форма где все элементы прорисовывается пару сек. т.е. не совсем интерактивно.
22 Sapiens_bru
 
13.10.19
15:51
(0) 30-40тыс записей это ниочем для СУБД.
Если среди реквизитов не будет хранилищ значения - самый быстрый вариант будет размещать реквизиты в шапке.
Если хранилища будут (картинки например) их лучше разместить в отдельном регистре сведений или справочнике.
Если точный состав реквизитов неизвестен заранее - тут уже не до скорости, делай ПВХ с размещением в регистре или ТЧ.
Размещать что-то в отдельных подчиненных справочниках можно если они сами по себе будут иметь ценность, как объекты учёта/настройки, будут иметь свои формы и реквизиты.
23 Shark_2000
 
14.10.19
00:19
(22) Реквизиты заранее известны они на 60% простых типов (номер кадастра - строка 100, дата + ссылка + дата + число + и т.д. ... вопрос в том что хранить 40+ измерений + ресурсов в одном регистре не вариант делать пакеты и соединения - практика показывает что это долго (при соединении 9 таблиц по около 2к-3к элементов это секунд 5 причем на виртуалке выделено 8 ядер и 64гб оперативки (на i9)). а если ежемесячные начисления??? всё((( потухнем... 30к элементов да еще штук по 6-9 услуг + пеня на каждую услугу + выгрузка в кассы + выгрузка в соц органы + печать квитанций.... ДА НАХ__Й ОНО НУЖНО!!! надо продумать всё сейчас и грамотно без юмора. Господа реальные ответы. как оптимизировать?!
24 H A D G E H O G s
 
14.10.19
00:23
(23) Никто не говорит про регистр, все ведут речь про справочник.
25 H A D G E H O G s
 
14.10.19
00:24
(23) Посмотри на типовые. Там не 40, там 40 тыс реквизитов и как то все сделано так, что все работает. Может у вас архитектор - рукожоп?
26 Shark_2000
 
14.10.19
00:27
(25) Может)))) а может у них по 40 тыс там где пользуешься раз в год????
27 H A D G E H O G s
 
14.10.19
00:28
(26) Вряд ли. Страна большая - пользуются всеми.
28 Shark_2000
 
14.10.19
00:32
(27) Брось))) у них много измерений только... ну на вскидку Организации. Сколько раз "Вся страна" пользуется? думаю что в среднем 2 раза))) просто 1млн это сделал 1раз и еще 1 человек сделал это много))) ну смысл понятен)))
29 Shark_2000
 
14.10.19
00:33
а все остальное напичкано навозом явно не под глобальные решения
30 H A D G E H O G s
 
14.10.19
00:36
(28) Ты просто не запускал решения, где пользователей, ну, допустим, больше 500 и документов, ну, допустим, больше 10тыс в сутки.

Именно на таких объемах, ты с удивлением обнаруживаешь такие невероятные варианты развития событий, какие не мог бы представить в обычной жизни.
31 palsergeich
 
14.10.19
00:36
На таком объеме смысла в оптимизации нет.
Соптимизируешь сотню мегабайт, и догонишь это текстами запросов.
32 palsergeich
 
14.10.19
00:38
Соединения с другими таблицами они не бесплатные ни разу
33 Shark_2000
 
14.10.19
00:38
(30) Думаю что ты прав. Я не сталкивался. Но нормального решения ЖКХ нет.
34 Shark_2000
 
14.10.19
00:40
(31) Вопрос не места, а производительности, но совет дельный.
35 Shark_2000
 
14.10.19
00:40
(32) А вот тут и проблема
36 palsergeich
 
14.10.19
00:42
(34) Для того что бы выбрать вариант реализации надо узнать как это будет использоваться.
В самом общем случае - оставляем и реквизиты - для того что бы объект был целостный и делаем еще хранилище на РС для того что бы найти объект по свойству, а то и нескольтко
37 Shark_2000
 
14.10.19
00:48
(36) Согласен, пусть раздуется база, но будет видно что дороже... хороший подход но временный, потом придется все резко править.
38 Shark_2000
 
14.10.19
00:48
Спасибо всем
39 H A D G E H O G s
 
14.10.19
00:50
В таких случаях специалисты начинают жись с вопроса - "А что у вас тормозит?" и собирают техжурнал.
А особо прошаренные говорят "мы, гусские, не обманываем друг друга" и собирают дополнительно APDEX... :-)

Но я против 2 варианта, я лучше знаю, что у кого тормозит. APDEX собирают неуверенные в себе, саморефлексирующие парни, которым надо потом отчитываться.
40 palsergeich
 
14.10.19
00:51
(37) Не придется.
Максимум что будет еще - это наиболее часто используемые области поиска вывести в отдельные сущности.
Сохранение реквизитов именно в объекте гарантирует что пользователь сохранит данные именно в том виде, в котором хотел, это обеспечит объектная блокировка и версия объекта платформенная. РС - этого не обеспечит.
41 palsergeich
 
14.10.19
00:54
(40) А для того что бы любое изменение не приводило к переписыванию 100% кода - посмотрите как хотябы реализован БСП.
Огромное количество микро АПИ.
И сделайте так же. Не важно что там на уровне данных, подав на вход первое, получите на выходе второе, при необходимости изменения - просто переписывается функция и все, остальнойкод неизменен
42 Glavkomnn
 
14.10.19
02:06
почему не воспользоваться типовым ПВХ "ДополнительныеРеквизитыИСведения". Его как раз для этих целей и разрабатывали
43 Glavkomnn
 
14.10.19
02:09
и там более менее внятно решено все с производительностью

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

но 30 тыс элементов с 40 реквизитами - это еще не объем, которому нужна производительность

если бы было 300 тыс элементов и 400 реквизитов - тогда ьы стоило что-то думать. Но и то не факт что можно что-то придумать лучше того что есть в типовом функционале
44 rphosts
 
14.10.19
03:59
(39) Апдекс - объективный показатель данный на не в ощущениях, а в замерах времени.
45 Cyberhawk
 
14.10.19
08:38
(44) Какой же он объективный, если он аномальные отклонения отбрасывает
46 тарам пам пам
 
14.10.19
08:59
(44) Целевое время человек выбирает, он по определению не может быть объективным.
47 Cyberhawk
 
14.10.19
09:15
(46) Ну от АПДЕКСа явно не эту итоговую оценку брать предлагается, а только сырые данные замеров
48 gSha
 
14.10.19
09:21
забей .. лучше думай как от теток из жэка будешь спасаться ..
там перерасчеты куда интереснее в жизни , чем какая то оптимизация кода
49 palsergeich
 
14.10.19
10:11
(43) К доп реквизитам, особенно если их много - обращение запросом - такое себе.
50 palsergeich
 
14.10.19
10:12
(49) Уточню. когда надо запросом получить 5-8 доп реквизитов)
51 Cyberhawk
 
14.10.19
10:17
(50) Причем безотносительно того, в ТЧ объекта они сидят или в регистре сведений
52 rphosts
 
14.10.19
10:35
(47) разумеется.
(45) вот как раз на исходных можно отловить аномалии, если они в определенные периоды времени возникают или с каким-то периодом - это может быть очень серьёзным источником данных для поиска проблемы.