опять вопрос про "много" реквизитов в справочнике (или документе)

[andron81_81]

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

Опишу ещё раз мою ситуацию. Есть справочник в нем очень много реквизитов 200-300 или более. Все они статичны (задаю их набор я), но некоторые из них в каком-то элементе справочника будут заполнены, а некоторые нет, то есть будут много элементов справочника у которых скажем будут заполнены 15 реквизитов.  вопрос теперь следующий, а рационально ли в справочнике размещать статически все эти реквизиты в таком большом объеме. Может существует другой способ ? Например характеристики . Или полную глупость предлагаю ?

[ilyay]

Задача неизвестна, поэтому определенно ничего сказать нельзя.

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

Характеристики тоже вариант, со своими плюсами и минусами.

[andron81_81]

Задача неизвестна, поэтому определенно ничего сказать нельзя.

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

Спасибо за отклик .

Задача такая : есть заказ в нем очень много параметров пусть их будет 500 их список конечен, и задаю его я. Значения некоторых параметров должен вводить пользователь, а некоторые расчетные(их будет рассчитывать при нажатии кнопки расчет ) исходя из того что ввёл менеджер. На деле некоторые в некоторые могут вноситься значения пользователем , а некоторые просто игнорируются и при расчете так же в них прописываться ничего не будет , то есть как бы пустышки в этом случае там будут . Вопрос: как это спроектировать с точки зрения хранения этих параметров их ввода и просмотра. Самый главный вопрос как с точки зрения хранения. Я могу тупо создать документ в нем статично пробить эти 500 реквизитов, но некоторые из них, а их может быть много (исходя из особенностей заказа) просто не будут содержать никаких значений. Но зарезервированы они будут (так как я их статично спроектировал в документе), а хорошо ли это ? может можно как-то иначе ?

[ilyay]

Лучше использовать характеристики.
Предположим, вам понадобилось добавить 501-е поле - придется реструктуризировать базу, выгонять пользователей, менять логику программы, чтобы она учитывала новое поле.
Кроме того, не будут храниться реквизиты, которые не существуют.
Отчеты умеют работать с характеристиками.

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

С точки зрения СУБД 500 реквизитов - это очень много для таблицы. Каждый объект - это строка таблицы. Чем больше реквизитов, тем меньше объектов помещается на страницу памяти. При работе с такими таблицами получится интенсивный ввод/вывод. А учитывая, что используется 3% реквизитов от полного списка - это очень неоптимально.

Если вам понадобится поиск по реквизитам, по характеристикам его будет сделать проще.

[oleg-x]

Можно использовать доп реквизиты. Сделать регистр сведений, связанный с документом/справочником. И если у тебя есть набор реквизитов которые используются только в определенных ситуациях, то вывести в регистр.
Еще как вариант, наверняка есть набор реквизитов, которые связаны между собой всегда, сделать их ввиде справочника, тогда в документе у тебя будет вместо 10 реквизитов 1.
Для примера можешь посмотреть в стандартных конфигурация такую вещь как характеристики.
Есть номенклатура и характеристика. Номенклатура всегда одна, а вот характеристики номенклатуры разные, она уже может содержать информацию о цвете, штрих коде, размере и прочее и все это в одном дополнительном справочнике.

[andron81_81]

С точки зрения СУБД 500 реквизитов - это очень много для таблицы. Каждый объект - это строка таблицы. Чем больше реквизитов, тем меньше объектов помещается на страницу памяти. При работе с такими таблицами получится интенсивный ввод/вывод. А учитывая, что используется 3% реквизитов от полного списка - это очень неоптимально.

вот , вот это самое главное о чем я и подразумевал. Вы меня услышали.
Значит характеристики !!!
Всем спасибо.

[andron81_81]

Лучше использовать характеристики.
Предположим, вам понадобилось добавить 501-е поле - придется реструктуризировать базу, выгонять пользователей, менять логику программы, чтобы она учитывала новое поле.
Кроме того, не будут храниться реквизиты, которые не существуют.
Отчеты умеют работать с характеристиками.

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

С точки зрения СУБД 500 реквизитов - это очень много для таблицы. Каждый объект - это строка таблицы. Чем больше реквизитов, тем меньше объектов помещается на страницу памяти. При работе с такими таблицами получится интенсивный ввод/вывод. А учитывая, что используется 3% реквизитов от полного списка - это очень неоптимально.

Если вам понадобится поиск по реквизитам, по характеристикам его будет сделать проще.

а вот с учетом выясненных в других темах ньюансов работы программы 1с (причем с вашей помощью - спасибо ) можно попробовать все эти реквизиты в количестве 500(хоть 1000) штук расположить в табличных частях документа.
особенности :
1. каждая строка табчасти это имя реквизита , значение.
2. значение будут иметь тип строка .
3. если надо для определённых реквизитов по нажатию на поле "выбрать вариант" справа от значения можно выбрать вариант из списка (все варианты будут содержаться в справочнике и выводиться в список выбора они будет исходя какой реквизит выбран) . При выборе значение будет прописываться в поле значение которое можно при желании подредактировать.

Хотелось бы получить Ваш вердикт по поводу реально ли реализовать такую концепецию и насколько это с точки зрения хранения данных , производительности и т.п.
я пока пробую реализовать

[ilyay]

Я бы рекомендовал характеристики, потому что:
1. Они позволяют задать разные типы для значений, в том числе варианты.
2. Они могут храниться в табличной части объекта, а не на регистре сведений, если для вас это важно.
3. 1С может отображать их как реквизиты, в СКД например.
4. Список реквизитов может быть четко определен и типизирован.

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

Плюс табличной части в том, что при копировании объекта будут скопированы и табличные части, а данные на регистре должны копироваться отдельно. Ну и не надо специально отбирать их, как это происходит с регистром. Впрочем, есть обработчик в модуле объекта, в котором можно прописать копирование записей регистра.

[andron81_81]

Я бы рекомендовал характеристики, потому что:
1. Они позволяют задать разные типы для значений, в том числе варианты.

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

2. Они могут храниться в табличной части объекта, а не на регистре сведений, если для вас это важно.

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

3. 1С может отображать их как реквизиты, в СКД например.

ну ничего страшного. обойдусь без СКД

4. Список реквизитов может быть четко определен и типизирован.

сомнительный плюс

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

а вот это аргумент ! то есть выигрыш в скорости .
где мы проигрываем в скорости , когда используем таб. часть ?
наверно при открытии документа ? а при обработке данных. скажем расчет некоторых параметров это ведь на клиенте будет происходить ?

Плюс табличной части в том, что при копировании объекта будут скопированы и табличные части, а данные на регистре должны копироваться отдельно. Ну и не надо специально отбирать их, как это происходит с регистром. Впрочем, есть обработчик в модуле объекта, в котором можно прописать копирование записей регистра.

тоже аргумент не в пользу характеристик . черт побери

[ilyay]

Никто не заставляет вас использовать характеристики. Проектное решение принимать вам.

Чтобы записать что-то в табличную часть, нужно получить объект, внести изменения в табличную часть и записать объект. Чтобы записать в регистр сведений, получать объект не нужно. Это может быть как плюсом, так и минусом. Просто имейте ввиду.

Вопрос блокировок СУБД для вас сейчас вообще не актуален, я про него не буду писать.

Если вы даете пользователю редактировать табличную часть он может удалить/добавить строки, что возможно, необходимо контролировать.

Варианты можно и в справочник добавлять или запрещать добавлять.