когда лучше использовать справочник когда регистр сведений чем они отличаются
Регистр сведений. Справочник или регистр.
| 3. Другое | 82% (9) |  |
| 2. Регистр | 18% (2) |  |
| 1. Справочник | 0% (0) |  |
Всего мнений: 11
(0) За базАр за «лишнюю сущность» неплохобы ответить.
Всмысле чем это она лишняя?
Вопрос за то имеют / не имеют представление пока опустим.
(6) Такая возможность у вас есть уже сейчас. Называется подчиненный справочник.
Уникальный составной ключ? Так вот жеШ он : УИДВладельца + УИДЗаписи.
(24) Ещераз. Базар о «лишних сущностях» требует обоснования.
При изменении любого поля в строке справочника как изменившаяся помечается все строка. Со всеми возможными миллионом реквизитов. С помощью регистров свединий реквизиты, не являющиеся ведущими при обменах можно исключить.
Такое себе «вертикальное расщепление» из теории БД.
Ты правда уверен, что для всех случаев лишнее поле ГУИД (которое есть ссылка справочника) ну просто необходимо?
для которого нужно самостоятельно написать метод
автонумерации.
Обязательные свойства справочника:
Дополнительные свойства справочника:
— Не имеет собственного ГУИДа.
— На него нельзя ссылаться.
— Имеет составной первичный уникальный ключ, зависимый от набора измерений.
Дополнительные свойства:
— Может иметь измерения (значения, формирующие составной уникальный ключ)
У справочника с документом больше общего.
Вот бизнес-процесс с документом можно было бы и объединить.. и то различия большие.
(49+) кроме того, неясна суть предложения об объединении.
Внести справочник с составным ГУИД-ом? и что с ним делать.
Варианта 2: а) на него можно ссылаться б) на него нельзя ссылаться.
Вариант (б) точно соответствует текущему регистру. Что за справочник, на который нельзя ссылаться? При чем тут будут код и наименование? К чему крепить таб. часть?
Рассмотрим вариант (а). ОК, сделали такой объект. В документе сослались на составной ГУИД (к примеру, из 3х измерений). После чего меняем в записи одно измерение. Составной ключ изменился. Что должно произойти со всеми ссылками?
Справочник или регистр сведений?
Подскажите начинающему программисту 8-ки.
В разрабатываемой системе учет товаров ведется по цветам размерам.
Смотрел аналоги, данные о цветах и размерах хранятся в регистрах сведений.
В нашей конфигурации я создал подчиненные справочнику номенклатура справочники: цветов и размеров. Я так и оставлю.
Вопрос в том что использовать эффективнее, справочник «Описатель короба» или регистр сведений?
В 7-ке, которую переделываем, понятное дело что это были справочники.
В чем преимущества и недостатки справочника и регистра сведений?
Заполняется все автоматически обработками, импорами, экспортима. Товаров десятки тысяч, вариантов цветов/размеров на каждый товар в среднем 10-15.
Спасибо, всем кто откликнется
Затем к цветам и размерам добавится полнота. Или тип ткани. Или еще какая-то хрень. Программеру работы до пенсии.
Чем УПП-шные характеристики не устраивают?
Спасибо, отвечу сразу всем, так как в каждом ответе есть полезная инфа:
По поводу того что добавиться, так это за 15 лет работы корпорации уже известно, то что проше характеристиками делать так это так и сделал:
И еще с пару десятков дополнительных свойств, и если пользоваться стандартными характеристиками и нагружать 1 регистр, то я приблизительно посчитав остатки и все что будет с этим связанно, при переносе актуальных данных в 8-ку, могу сказать что строк в таблице будет несколько десятков миллионов.
К сожалению велосипед с квадратными колесами уже катается 5 лет на 7-ке, а в главном офисе корпорации с момента появления платформы, от разработанного стандарта отходить нельзя и переделывать всю сеть офисов и магазинов и форматы обменов никто не будет, учитывая что это разные страны и разное законодательство.
Поэтому и хочется максимально эффективно использовать возможности,а новое не всегда оптимальное.
Надеюсь теперь понятем смысл моего вопроса. Интересует не теория а практика, не хочется потом переделывать, когда начнутся проблемы.
Если кому интересно, то что мне нужно на регистре сведений делать нельзя.
Только сейчас понял все что отвечали 🙂
Немного о регистрах в 1с
В любой конфигурации 1с 8.2 можно увидеть такой вид объектов, как регистры. Основное их предназначение — оптимизация получения данных для отчетов. Существует четыре вида реистров: регистры сведений, регистры накоплений, регистры бухгалтерии и регистры расчета. И хотя предназначены эти виды для решения разных задач, уже по тому, что они все называются «регистрами» можно догадаться, что они имеют и нечто общее.
Во-первых, как уже упоминалось, как объекты конфигурации они нужны для более быстрого считывания информации из базы данных, например в запросах. Регистры можно сравнить с каталогом книжной библиотеки (раньше их составляли на бумажных карточках). То есть это не только хранение информации (данных), но и ее систематизация (создание определенной структуры), когда в конкретный регистр попадают данные (например, из документов разного вида) и при необходимости ее можно достаточно быстро оттуда извлечь и вывести, например, в отчет или обработать иным образом. В общем случае основное использование регистров в 1с можно изобазить следующей схемой: «Документ — Регистр — Отчет», хотя существуют и исключения.
В-третьих, регистры имеют табличную структуру, но она отличается от структуры объектных таблиц. Так что вы не найдете таких классов, как РегистрСсылка или РегистрОбъект. Состав таблицы регистра зависит от его свойств.
В-четвертых, данные в регистры записываеются в виде наборов записей. Каждый набор состоит из одной или нескольких записей. При этом на запись в наборе нельзя сослаться или обратиться к ней. А также ни набор записей, ни запись в наборе не могут иметь состояния «пометка на удаление».
В-пятых, при обращении в запросах к регистрам для получения данных существует возможность обратиться не только к физическим таблицам регистра, но и к виртуальным таблицам, которые представляют из себя вложенный запрос, получающий данные по определенным параметрам. Параметры виртуальной таблицы задаются в зависимости от конкретных потребностей по получению данных из таблиц регистров.
Терперь поговорим об особенностях каждого вида регистров:
1. Регистры сведений
Пожалуй, самый простой вид регистра. В отличие от регистров другого вида, его ресурс может имень не только числовое значение, но и другой тип данных.
Имеет особое свойство, не используемое в других видах регистров — периодичность.
Может не иметь регистратора, то есть быть независимым, в этом случае записи производятся непосредственно в регистр, минуя регистрирующий документ (то самое исключение из общей схемы использования регистров в 1с). Тогда как остальные виды регистров должны иметь хотя бы один документ-регистратор.
Кроме того, данный вид регистра имеет автоматический контроль уникальности записей по периоду (периодичность, указанная в свойствах регистра) и измерениям. То есть среди записей регистра не может быть более одной записи с одинаковыми показателями период+измерение+регистратор(если он есть). Уникальность записей в других видах регистров осуществляется по регистратору.
2. Регистры накоплений
Предназначен для накопления числовых покателей (ресурсов) и делится на два подвида — Остатки и Обороты. Отличие между ними заключается в том, что Регистр накопления Остатки предназначен для получения информации о состоянии «на момент времени», а Обороты — информации о данных «за период».
Данные регистра накопления хранятся в БД в виде двух таблиц — таблица движений и таблица итогов. Обращение напрямую возможно только к таблице движений.
3. Регистры бухгалтерии
Похож на регистр накопления, но предназназначен для систематизации данных о бухгалтерских проводках. Впрочем он может использоваться не только для бухгалтерского, но и для любого другого вида учета.
4. Регистры расчета
Этот вид регистра предназначен не только для хранения, накопления и систематизации данных, но и для реализации сложных механизмов периодческих расчетов. Для этого в свойствах регистра расчета необходимо определить еще один объект 1с — план видов расчета. То есть работа регистра этого вида невозможна без определения для него конкретного плана видов расчета.
Можно сказать, что регистр расчета используется и для хранения информации о видах расчета, и для хранения результатов расчетов, и для промежуточных значений расчетов. Основное его предназначение в конфигурациях 1с — это расчеты начислений, например, заработной платы и других выплат сотрудникам. И для реализации этих задач при определении параметров регистра расчета, в нем возможно указать связь с графиком времени, что позволяет производить расчеты в зависимости от того времени, которое задано в этом графике. Сам график времени должен быть определен с помощью соответствующего регистра сведений.
Таким образом, можно сказать, что регистр расчета имеет в итоге самую сложную структуру по сравнению с другими видами регистров в 1с.
Отличия табличной части от регистра сведений
| 1. Табличная часть лучше | 50% (5) | |
| 2. Регистр сведений лучше | 50% (5) | |
Всего мнений: 10
(5) Не надо мяу, я прекрасно знаю ответ на заданный в сабже вопрос :))
Чуть наведу на основную мысль, ради которой я и завел ветку.
Предположим, что нам надо в контрагентах хранить с десяток всяких разных таких вещей разного плана.
Где будете хранить, ТЧ или РС?
(0) Еще можно создать ДопСправочник, создать в исходном объекте (скажем, документ ЗаказПокупателя) реквизит типа СправочникСсылка.ДопСправочник (связь 1 к 1). В этом справочнике хранить дополнительные поля (реквизиты) и записывать их в определенные моменты (возможно, не перезаписывая основной объект). Очень может выручить в некоторых случаях.
ЗЫ. Где вариант «Другое»?
(16) Значит не уверен, раз спрашиваешь.
А вообще, похоже на обсуждение сферического коня в вакууме.
Какая-то сущность. Формируй точные задачи с указанием как будет та или иная сущность использоваться.
Короче вопрос дурацкий
(70) Я вообще-то привел вполне конкретные примеры, а не сферического коня в вакууме.
Короче, замечание дурацкое.
(74) Про то, что не подъежнул про курточку — это молодец. Показал, что чуть взрослее, чем те, кто считает, что здесь есть над чем уписаться.
А про пример согласене, что есть неопределенность некая.
Но тем не менее, многие вещи вполне себе определены.
Например то, что в данных ТЧ не будут храниться большие объемы данных типа приложенных файлов.
А, с другой стороны, хрен его знает, что может быть в допреквизитах. И сколько их.
Есть 8.2, управляемые формы и следующая задача:
1. Некая обработка, назовём её Писатель, идёт по базе и пишет задания в очередь.
2. Параллельно в фоне торчат 8-10 обработок, назовём их Читатели, которые мониторят очередь, хватают задания по принципу «кто успел, тот и съел» в той же последовательности, в которой они ставились в очередь (FIFO).
3. Писатель работает быстрее Читателя, поэтому до конца работы Писателя
очередь растёт.
4. В течение рабочего дня очередь то растёт, то уменьшается, иногда до нуля.
5. Необходимо контролировать, чтобы очередь была не длиннее, чем некоторое наперёд заданное значение.
6. Очередь должна быть сохраняться между перезапусками 1С.
===============================
ВОПРОС:
На чём её лучше организовать? На справочниках? Регистрах сведений? Заданиях? Или, может, какой специальный объект существует для этой цели? Или на чём?
(1) Если я правильно понял, нужно по порядку запускать задания (регламентные или просто выполнение кода, думаю не столь важно).
Начнем с того, нужно ли хранить историю задания (номер задания, когда запустилось, что обработало и пр) Если нет, то справочники не подойдут, т.к. нет смысла их хранить в таком количестве.
Регистры сведений более подойдут. Измерения в виде идентификатора задания, ресурсы Порядковый номер и какая-то служебная информация если потребуется. Это и будет очередь Читателей. Очередь заданий так же вполне реализуются регистрами сведений
Контроль распределения нагрузки более глубокий вопрос. Если заранее известно сколько по времени будет выполняться задание, их общее количество, количество, которое поступит за n времени то думаю можно что-то изобразить (прогноз) Иначе все будет очень условно.
Специальных объектов не существует, на сколько мне известно.
В смысле? По-моему и одного справочника достаточно. Или есть какой-то лимит на количество записей?
1. Добавление задания в Задания. Статус = Новое.
2. Обработка делает запрос и выбирает СрезПервых со статусом «Новое».
3. Переводит статус в «Выполнятся».
4. После выполнения переводит в статус «Выполнено».
5. Повторяет с шага 2.
Тут несколько тонкостей.
шаг. 4. Возможно стоит переделать на удаление выполненной задачи. Чтоб не увеличивать размер РС. Возможно для хранения информации переносить выполненную задачу в новый РС.
Далее. Позаботиться о правильном доступе фоновых заданий к этому РС. Чтобы не хватали один и тот же элемент. Возможны блокировки.
Да по-любому доли секунды ни взять всё равно неоткуда будет, ни записать путём.
А это МЫСЛЬ. Спасибо!
Можно и с пустым. Так ещё легче. Или регистр не допускает задания пустых измерений?
А можно поподробнее?
С блокировками у регистров всё так же, как и у справочников? Или есть какие-то нюансы?