Вход | Регистрация
 
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 или кнопку "Обновить" в браузере.