Добрый день!
Коллеги подскажите, пожалуйста.
Самописная конфигурация под управляемым приложением.
Задача:
Серверная функция.
1. Необходимо выбрать список номенклатуры с остатками.
2. Некоторые позиции номенклатуры доступны для отгрузки только конкретным контрагентам .
3. Необходимо определить список номенклатуры, доступной текущему контрагенту.
На ум приходят два варианта хранения связи между номенклатурой и контрагентами.
Вариант 1: В элементе справочника номенклатуры создать табличную часть со списком контрагентов.
Вариант 2: Создать регистр сведений без ресурсов с измерениями Номенклатура и Контрагент.
Собственно вопрос:
В каком варианте хранения связи Контрагент-Номенклатура запрос будет работать быстрее (с учетом того, что перед определением принадлежности номенклатуры к контрагенту список номенклатуры уже выбран (т.е. табличная часть уже есть в кэше на сервере)?
Т.е. что быстрее: заново подтянуть регистр по списку номенклатуры и выбрать подходящую для конкретного контрагента, или выбрать контрагентов из табличной части уже выбранной номенклатуры?
Вопрос вроде бы простой, но для нас важный, т.к. список выбираемой номенклатуры может достигать десяти тысяч позиций, и данная процедура может выполняться до нескольких раз в минуту.
Спасибо.
Коллеги подскажите, пожалуйста.
Самописная конфигурация под управляемым приложением.
Задача:
Серверная функция.
1. Необходимо выбрать список номенклатуры с остатками.
2. Некоторые позиции номенклатуры доступны для отгрузки только конкретным контрагентам .
3. Необходимо определить список номенклатуры, доступной текущему контрагенту.
На ум приходят два варианта хранения связи между номенклатурой и контрагентами.
Вариант 1: В элементе справочника номенклатуры создать табличную часть со списком контрагентов.
Вариант 2: Создать регистр сведений без ресурсов с измерениями Номенклатура и Контрагент.
Собственно вопрос:
В каком варианте хранения связи Контрагент-Номенклатура запрос будет работать быстрее (с учетом того, что перед определением принадлежности номенклатуры к контрагенту список номенклатуры уже выбран (т.е. табличная часть уже есть в кэше на сервере)?
Т.е. что быстрее: заново подтянуть регистр по списку номенклатуры и выбрать подходящую для конкретного контрагента, или выбрать контрагентов из табличной части уже выбранной номенклатуры?
Вопрос вроде бы простой, но для нас важный, т.к. список выбираемой номенклатуры может достигать десяти тысяч позиций, и данная процедура может выполняться до нескольких раз в минуту.
Спасибо.
По теме из базы знаний
- Универсальная загрузка из файла (без разрывов страниц)
- Загрузка данных из табличного документа в справочники, документы, планы видов характеристик, планы видов расчетов, планы счетов, бизнес-процессы, задачи, в движения документов, поточная загрузка документов (EXCEL, управляемые формы, универсальная)
- Версионирование справочников, документов и регистров сведений на SQL-сервере
- Когда много строк в документе: Удобный редактор табличных частей
- Регистры расчёта для начинающих
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) типовые в этом отношении склоняются к регистрам сведений (номенклатура контрагентов), кроме того в регистре можно предусмотреть указывать не только контрагента или номенклатуру, но и группу контрагентов, группу номенклатуры, номенклатурную группу, ценовую группу и т.д.
если нет инфы в разрезе даты, то что регистр, что справочник - одна и та же по содержанию и смыслу таблица. Нюансы могут быть если только на уровне реализации самой 1С-кой запросов к этим разным объектам метаданных - и проверить их лучше опытным путём.
Если в этот регистр/справочник не будут в эту же минуту с такой же интенсивностью записываться данные, то данные выборки узким местом быть не должны.
Если в этот регистр/справочник не будут в эту же минуту с такой же интенсивностью записываться данные, то данные выборки узким местом быть не должны.
(6) Можно, но только не владельца. Т.е. для номенклатуры можно сделать табличную часть, но если захотим сделать тоже самое для номенклатурной группы нужно будет заводить ещё одну табличную часть и т.д. Регистр сведений в этом отношении гибче.
8.
FreeArcher
164
01.09.11 12:00
Сейчас в теме
Только проверять. Правильно говорят в базе это 2 таблицы. И не забудьте про индексы!
ПВХ - это по сути тот же регистр сведений.
Тем более, что он у нас уже заведен, и некоторую часть реквизитов объектов мы храним в ПВХ.
Устанавливаем необходимый отбор в виртуальной таблице срез последних по регистру со значениями ПВХ. И все. Получаем тот же срез последних, что и по обычному регистру.
Коллеги, если я не прав, опровергните меня, пожалуйста. Был бы признателен :-)
Тем более, что он у нас уже заведен, и некоторую часть реквизитов объектов мы храним в ПВХ.
Устанавливаем необходимый отбор в виртуальной таблице срез последних по регистру со значениями ПВХ. И все. Получаем тот же срез последних, что и по обычному регистру.
Коллеги, если я не прав, опровергните меня, пожалуйста. Был бы признателен :-)
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот