Вход | Регистрация
 
1С:Предприятие :: 1С:Предприятие 8 общая

оптимизация хранения данных

оптимизация хранения данных
Я
   Shark_2000
 
13.10.19 - 14:16
Всем Добрый день.

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

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

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

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

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

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

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

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

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

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


Список тем форума
Рекламное место пустует  Рекламное место пустует
Пользователь не знает, чего он хочет, пока не увидит то, что он получил.
Э. Йодан
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.