Всем Добрый день.

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

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

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

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

Заранее Спасибо!

(0) там сейчас все справочники такие, в чем вопрос?

Ну, 30000 тыс это, видимо, опечатка. Но даже 30 тыс справочников по 40 реквизитов? Моделью каких данных это является, даже интересно...

(0) > реквизиты будут заполняться не у всех.

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

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

А еще можно перенести в ТЧ справочника.

(2) > Моделью каких данных это является, даже интересно...

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

Для одной номенклатуры нужны: "размер штанов, размер рубашки, размер головы", для другой: "длина, ширина, диаметр, марка стали" и т.п.

(0) в программировании не существует единственно правильных ответов для всех случаев. Без конкретики разговора не получится.

(2) это будет подсистема ЖКХ, и 30 тыс. это даже не предел. Справочник помещения и лицевые счета.

(0) С точки зрения работы лучше оставить один реквизит, куда записывать все прочие в виде JSON.
А для выборок/поиска использовать хеширование.

(3) Свойства объектов не подходят... кто их будет заполнять в ручную...

(7) подробнее....

(6) Подразумевал вероятно под 30к кол-во элементов справочника а не разных видов справочников каждый со своими 40 реквизитами и хз сколько элементов.

(9) Подробнее изучают в ВУЗах или самостоятельно.

(10) Да

(11) Это не новость... Хоть где искать???

(12) Если это 8-ка то сделай ТЧ разные по "заполняться не у всех".
Банально и просто.

(14)+ В смысле ТЧ в которой будет всего одна строка с набором реквизитов-полей или не будет если для данного элемента не нужна.

(14) ТЧ не идет.... https://its.1c.ru/db/metod8dev#content:2706:hdoc

данные делятся на группы, кадастровые данные, ГИС ЖКХ, Регл. учет, и прочее.

(2) 30000 элементов похоже

Забей и воткни все в реквизиты.

Потомки тебе спасибо скажут.

(0) ээээ, может не "таких справочников будет около 10 000 - 30 000 тыс" а элементов в справочнике?
(19) +1. Ну может только что-то типа строка неограниченной длины перевести в подчинённые, а так 40 =- не много. У меня была жесть где 200+ элементов... единственная проблема - форма где все элементы прорисовывается пару сек. т.е. не совсем интерактивно.

(0) 30-40тыс записей это ниочем для СУБД.
Если среди реквизитов не будет хранилищ значения - самый быстрый вариант будет размещать реквизиты в шапке.
Если хранилища будут (картинки например) их лучше разместить в отдельном регистре сведений или справочнике.
Если точный состав реквизитов неизвестен заранее - тут уже не до скорости, делай ПВХ с размещением в регистре или ТЧ.
Размещать что-то в отдельных подчиненных справочниках можно если они сами по себе будут иметь ценность, как объекты учёта/настройки, будут иметь свои формы и реквизиты.

(22) Реквизиты заранее известны они на 60% простых типов (номер кадастра - строка 100, дата + ссылка + дата + число + и т.д. ... вопрос в том что хранить 40+ измерений + ресурсов в одном регистре не вариант делать пакеты и соединения - практика показывает что это долго (при соединении 9 таблиц по около 2к-3к элементов это секунд 5 причем на виртуалке выделено 8 ядер и 64гб оперативки (на i9)). а если ежемесячные начисления??? всё((( потухнем... 30к элементов да еще штук по 6-9 услуг + пеня на каждую услугу + выгрузка в кассы + выгрузка в соц органы + печать квитанций.... ДА НАХ__Й ОНО НУЖНО!!! надо продумать всё сейчас и грамотно без юмора. Господа реальные ответы. как оптимизировать?!

(23) Никто не говорит про регистр, все ведут речь про справочник.

(23) Посмотри на типовые. Там не 40, там 40 тыс реквизитов и как то все сделано так, что все работает. Может у вас архитектор - рукожоп?

(25) Может)))) а может у них по 40 тыс там где пользуешься раз в год????

(26) Вряд ли. Страна большая - пользуются всеми.

(27) Брось))) у них много измерений только... ну на вскидку Организации. Сколько раз "Вся страна" пользуется? думаю что в среднем 2 раза))) просто 1млн это сделал 1раз и еще 1 человек сделал это много))) ну смысл понятен)))

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

(28) Ты просто не запускал решения, где пользователей, ну, допустим, больше 500 и документов, ну, допустим, больше 10тыс в сутки.

Именно на таких объемах, ты с удивлением обнаруживаешь такие невероятные варианты развития событий, какие не мог бы представить в обычной жизни.

На таком объеме смысла в оптимизации нет.
Соптимизируешь сотню мегабайт, и догонишь это текстами запросов.

Соединения с другими таблицами они не бесплатные ни разу

(30) Думаю что ты прав. Я не сталкивался. Но нормального решения ЖКХ нет.

(31) Вопрос не места, а производительности, но совет дельный.

(32) А вот тут и проблема

(34) Для того что бы выбрать вариант реализации надо узнать как это будет использоваться.
В самом общем случае - оставляем и реквизиты - для того что бы объект был целостный и делаем еще хранилище на РС для того что бы найти объект по свойству, а то и нескольтко

(36) Согласен, пусть раздуется база, но будет видно что дороже... хороший подход но временный, потом придется все резко править.

Спасибо всем

В таких случаях специалисты начинают жись с вопроса - "А что у вас тормозит?" и собирают техжурнал.
А особо прошаренные говорят "мы, гусские, не обманываем друг друга" и собирают дополнительно APDEX... :-)

Но я против 2 варианта, я лучше знаю, что у кого тормозит. APDEX собирают неуверенные в себе, саморефлексирующие парни, которым надо потом отчитываться.

(37) Не придется.
Максимум что будет еще - это наиболее часто используемые области поиска вывести в отдельные сущности.
Сохранение реквизитов именно в объекте гарантирует что пользователь сохранит данные именно в том виде, в котором хотел, это обеспечит объектная блокировка и версия объекта платформенная. РС - этого не обеспечит.

(40) А для того что бы любое изменение не приводило к переписыванию 100% кода - посмотрите как хотябы реализован БСП.
Огромное количество микро АПИ.
И сделайте так же. Не важно что там на уровне данных, подав на вход первое, получите на выходе второе, при необходимости изменения - просто переписывается функция и все, остальнойкод неизменен

почему не воспользоваться типовым ПВХ "ДополнительныеРеквизитыИСведения". Его как раз для этих целей и разрабатывали

и там более менее внятно решено все с производительностью

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

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

если бы было 300 тыс элементов и 400 реквизитов - тогда ьы стоило что-то думать. Но и то не факт что можно что-то придумать лучше того что есть в типовом функционале

(39) Апдекс - объективный показатель данный на не в ощущениях, а в замерах времени.

(44) Какой же он объективный, если он аномальные отклонения отбрасывает

(44) Целевое время человек выбирает, он по определению не может быть объективным.

(46) Ну от АПДЕКСа явно не эту итоговую оценку брать предлагается, а только сырые данные замеров

забей .. лучше думай как от теток из жэка будешь спасаться ..
там перерасчеты куда интереснее в жизни , чем какая то оптимизация кода

(43) К доп реквизитам, особенно если их много - обращение запросом - такое себе.

(49) Уточню. когда надо запросом получить 5-8 доп реквизитов)

(50) Причем безотносительно того, в ТЧ объекта они сидят или в регистре сведений

(47) разумеется.
(45) вот как раз на исходных можно отловить аномалии, если они в определенные периоды времени возникают или с каким-то периодом - это может быть очень серьёзным источником данных для поиска проблемы.