|
оптимизация хранения данных | ☑ | ||
---|---|---|---|---|
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
|
(14) ТЧ не идет.... https://its.1c.ru/db/metod8dev#content:2706:hdoc
|
|||
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) вот как раз на исходных можно отловить аномалии, если они в определенные периоды времени возникают или с каким-то периодом - это может быть очень серьёзным источником данных для поиска проблемы. |
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |