10.10.11 — 12:18
Народ!
Для реализации одного механизма требуется сопоставление склада и склада резерва.
Одному складу ВСЕГДА будет соответствовать ОДИН склад резера.
Как лучше реализовать сопоставление?
Через реквизит «СкладРезерва» или через регистр сведений «Склад — Склад Резерва»
Спасибо!
1 — 10.10.11 — 12:18
и на зачем тут регистр заводить? голосовалку? 
2 — 10.10.11 — 12:20
Если человеку каждый раз хочется лазить ещё в одну таблицу (для других целей и даром не нужную) — то почему бы и не завести регистр сведений?
3 — 10.10.11 — 12:20
(0)РС только если нужно хранить историю..а так — реквизита вполне хватит
4 — 10.10.11 — 12:20
(2) может, у него зарплата от количества таблиц зависит
5 — 10.10.11 — 12:30
каждый вздох — таблица
все что не относится к сущности (модели объекта) —
в другие сущности.
тем более сопоставления.
6 — 10.10.11 — 12:32
В регистр. Дабы не утежелять чтение объекта везде и всегда, только для «одного механизма».
7 — 10.10.11 — 12:33
(6)Не утяжеляя чтение объекта, ты утяжеляешь базу лишней сущностью.
8 — 10.10.11 — 12:34
(7) а тут уже надо смотреть в корень — хз что там за механизм будет…
9 — 10.10.11 — 12:35
регистр сведений делается в двух случаях
1. разделение прав на записть справочника и свойств
2. требуется переодичность
все остальное — от лукавого
10 — 10.10.11 — 12:37
(9) у меня доп признаки для документа вынесены в РС
11 — 10.10.11 — 12:39
(10) согласен, зачем при чтении лишнее читать в (9) этого нет
12 — 10.10.11 — 12:40
(7) Я сказал только свое мнение. Конкретное решение на самом деле может зависить от многих факторов. Но если упростить до «реквизит vs регистр» — то мое мнение таково. Все лишешнее — из объекта убрать. Не навязываю.
13 — 10.10.11 — 12:41
(12) Если убрать все лишнее отстанутся только код и наименование.
14 — 10.10.11 — 12:42
В регистр. но — если человек умеет с ним пользоваться (в отчетах кода надо будет писать больше). А потому что данные будут выглядеть наглядней.
15 — 10.10.11 — 12:46
(9) 3. Для совместимости с будущим обновлением
Т.е. завел РС и голова не болит, что новое обновления затрет твой реквизит
16 — 10.10.11 — 12:47
Решение через реквизит:
Минусы:
— В таблицу справочника добавляется колонка и для всех складов будет хранится значение Склада резерва.
— Если вдруг для склада необходимо будет два склада резерва, то все придется переделывать.
— Чтение и запись эл. спр. Склады будет выполняться дольше.
Плюсы:
— Простота реализации.
— Легко получать значение склада резерва.
— Во всех отчетах можно будет группировать, отбирать по складу резерва.
Решение через рс:
Минусы:
— Для получения склада резерва лишнее соединение с таблицей рс.
— Пользователь наверняка захочет в форме элемента спр. Склад видеть склад резерва — придется код писать.
Плюсы:
— хранится столько записей соответствий Склад — Склад резерва сколько действительно необходимо. Т.е. никакой избыточной информации.
— складов резерва для одного склада можно сделать много. и вообще возможности модификации такого механизма намного шире.
— не тягаем за складом — склад резерва при любом чтении и записи эл. спр. склад.
Выбор метода реализации зависит от задачи. Мне больше нравится через рс. Уверен что пользователи что-то забыли и только реквизитом будет не обойтись.
17 — 10.10.11 — 12:48
(15) это вам не семерка, «затирание» реквизиту мало грозит
18 — 10.10.11 — 12:50
А насчет «излишеств» — сколько планируется записей в справочнике «Склады»? Десятки тысяч?
Более жизненно ИМХО просто десятки максимум.
Так что реквизит вряд ли что-то заметно «утяжелит»
19 — 10.10.11 — 12:50
(17) Угу и на форму он автоматом добавиться? Или каждый раз будешь глазками сравнивать, так ничего нового в этом справочнике на форме не появилось
20 — 10.10.11 — 12:52
(16) Так вроде бы в 8.2 в конфигураторе можно пошаманить и запись в РС будет как реквизит видеться
21 — 10.10.11 — 12:53
Если в принципе, то в справочник нужно добавлять реквизит, если он будет заполнен у большинства элементов и будет использоваться часто, если нет — то регистр сведений. В данном случае, справочник склады обычно маленький, поэтому проще реквизит
22 — 10.10.11 — 12:54
(21) Сас себе противоречишь
23 — 10.10.11 — 12:54
если конфа на поддержке — то я за РС.
ну и никогда не говори «всегда»
24 — 10.10.11 — 12:57
(20) Т.е. можно отображение на форме элемента справочника связанного с этим справочником значения из какого-то рс решить только настройками свойств объектов конфигурации?
25 — 10.10.11 — 12:57
(22) в чем же?
26 — 10.10.11 — 12:58
(24) Да. И даже интеракитвный ввод и прочую хню, по крайней мере в 8.1
27 — 10.10.11 — 12:59
для регистра есть например такие подводные камни как подписка на событие, RLS и тд
например совсем не просто сделать подписку на изменение значения элемента справочника и т.д.
28 — 10.10.11 — 13:01
(25) см (21)
«справочник нужно добавлять реквизит, если он будет заполнен у большинства элементов…, если нет — то регистр сведений. В данном случае, справочник склады обычно маленький, поэтому проще реквизит»
Вывод неправильный .
Твое правило: если х = 1 то А, иначе Б
Состояние х = 1
Вывод: Б
29 — 10.10.11 — 13:01
(27) или например контроль уникальности чего-то
кроме того такое поле не выведешь в динамический список, проблеммы с сортировкой по нему….
30 — 10.10.11 — 13:05
(9) Еще в случае, когда на миллион записей данное значение будет заполнено у нескольких сотен…
31 — 10.10.11 — 13:08
(26) С использованием эл. формы поле ввода?
32 — 10.10.11 — 13:10
Зачем? Табличное поле или используй перейти
33 — 10.10.11 — 13:13
(32) Через таб. поле понятно как. Я уж было подумал что можно связать с полем ввода.
34 — 10.10.11 — 13:28
(28) Ну собственно тут не совсем противоречие. Если в справочнике склады будет большинство реквизитов заполнено (а в маленьком справочнике оно так и будет) то нужно реквизит.
35 — 10.10.11 — 13:30
А не лучше ли прямо в доке определять склад резерва и не засорять справочник?
36 — 10.10.11 — 13:33
(35) на основании чего? Причем это нужно сделать прозрачным для пользователя
37 — 10.10.11 — 13:35
(35) На основании решения пользователя.
38 — 10.10.11 — 13:39
(37) Пользователь выбрал склад А, автоматом должен выбраться резерв со склада Б
Если он выбрал склад АБВГД, то соответсвенно резерв со склада XYZ
А если он будет выбирать кучу реквизитов … так может и сумму не рассчитывать на основании цены и количество, а пусть сам менеджер ручками считает, «На основании решения пользователя.»
Irbis
39 — 10.10.11 — 13:44
(38) А как арифметика от воли пользователя меняется. А вот склад резерва вполне может. Потому что если связь «жесткая» один в один, реквизит вообще не нужен ни в справочнике, ни в документе.
Основная трудность, с которой сталкиваются начинающие изучать 1С, заключается в том, что быстро разобраться что здесь к чему очень сложно. В платформе 1С:Предприятие вводится целый ряд оригинальных понятий. Объяснений этих понятий во встроенной справке, на сайте 1С и на прочих ресурсах много, но они мало что проясняют даже искушенному в ИТ. Здесь я расскажу об одном важном понятии в 1С. Простыми словами и со смыслом.
Определение
Приведу для начала две цитаты.
Основная задача регистра сведений — хранить существенную для прикладной задачи информацию, состав которой развернут по определенной комбинации значений и, при необходимости, развернут во времени.
Это из встроенной справки. Ее еще называют синтакс-помощник. Слова тут простые, но если смотреть свежим взглядом, лишены какого-либо смысла. Есть регистр, который хранит существенную информацию? А что, есть регистр, который хранит чепуху? Что означает «развернутость» информации? Она была «свернута», а потом «развернулась»? Хотелось бы понять детали этого процесса!
Регистры сведений — это прикладные объекты конфигурации. Они позволяют хранить в прикладном решении произвольные данные в разрезе нескольких измерений.
А это с сайта 1С https://v8.1c.ru/platforma/registr-svedeniy/ Как можно что-то «хранить в разрезе»? Что тут «режется» и зачем?
Мое определение понятия «регистр сведений» звучит так.
Регистр сведений — это полный аналог таблицы базы данных.
Для тех, кто хоть немного знаком с базами данных, будет достаточно следующего дополнения.
В отличие от прочих объектов 1С:Предприятие, в регистре сведений есть возможность управлять первичным ключом.
Для тех, кто не знаком с теорией баз данных поясню, по возможности коротко и просто.
Большинство современных баз данных называются реляционными, потому что они состоят из таблиц. Так или иначе, все имели дело с таблицами. Таблица — это множество однотипных строк, и множество колонок. Как добраться до колонки понятно. Надо назвать ее по имени. А как добраться до конкретной строки в таблице? Для этого нам потребуется т.н. ключ. В самом простом случае ключом для конкретной строки является значение в одной из колонок.
В этой таблице ключи находятся в колонке «Идентификатор». Для того, чтобы однозначно определять строку по ключу, каждое значения ключа должно быть уникальным в пределах таблицы. Какой-бы большой не была таблица, поиск по ключу происходит очень быстро, потому что ключи особым образом компонуются в структуру под названием индекс.
При проектировании почти в любой базы данных так или иначе возникает ситуация, когда требуется создать таблицу, в которой значения ключей будут храниться не в одной колонке, а в нескольких. Например, у нас есть таблица товаров и таблица складов. Мы хотим создать таблицу, в которой будут отображаться цены товаров на складах.
Регистр сведений в платформе 1С:Предприятие позволяет явным образом указать ключ (его еще называют первичный ключ). Этим он и отличается от всех прочих объектов. Для них первичные ключи создаются автоматически и не подлежат изменению.
Можно сказать, что регистр сведений самый универсальный инструмент среди всех прочих в 1С. Посмотрим, что можно делать с ним.
Регистр сведений со множеством измерений
Измерение — это еще один термин родившийся в недрах 1С. Для регистра сведений измерение ни что иное, как часть ключа. Соответственно, множество измерений регистра сведений задает первичный ключ. Измерения есть и в других объектах платформы 1С:Предприятие (регистры накопления, регистры бухгалтерии, регистры расчетов), но там они обозначают нечто принципиально иное, на чем мы сейчас останавливаться не будем.
Такие объекты платформы, как справочник или документ создаются с предопределенным первичным ключом. Этот первичный ключ состоит из одного поля. В 1С его называют ссылкой. Если же нам требуется составной первичный ключ, тогда мы используем регистр сведений.
Один пример я уже дал выше. Еще несколько примеров:
-
цены товаров у поставщиков;
-
подразделение и занимаемая должность работника;
-
место хранения товара на складе;
-
настройки заполнения банковских выписок;
-
график работы сотрудника.
Регистр сведений с одним измерением
Такое встречается довольно часто, в том числе и в типовых конфигурациях. Тут надо понимать, что регистр сведений в этом случае не заменяет справочник, у которого тоже всего одно «измерение». Отличие тут принципиальное. «Измерение» справочника, которое в 1С называют ссылкой, заполняется автоматически при создании новых записей. В то время как в регистре сведений измерения заполняются либо пользователем, либо программно, но во втором случае нужны усилия разработчика. Обычно в качестве единственного измерения регистра сведений указывают ссылку на запись в справочнике или ссылку на документ. Далее в разделе ресурсы или реквизиты (разница между ресурсами и реквизитами в регистре сведений исчезающе мала и мы не будем ее здесь обсуждать) вводят некоторое количество полей. Таким образом получается, что у справочника или документа появились новые поля. Мы как будто расширили справочник или документ.
Конечно, такая практика приводит к некоторой путанице. Открываешь справочник(документ) в режиме пользователя, вот он реквизит. Можно редактировать. Открываешь справочник(документ) в Конфигураторе, нет реквизита! Ищи в другом месте. Но есть и плюс, который заключается в том, что исходный справочник(документ) остается в неизменном виде. И если возникает именно такая задача (внести изменения, но не «трогать» исходный справочник или документ), тогда используют регистр сведений с одним измерением.
Регистр сведений без «измерений»
Можно создать регистр сведений вообще без измерений. Это не будет означать, что у регистра сведений нет ключа вообще и можно вводить сколько угодно записей. Это будет означать, что ключ есть, он представляет собой пустое значение и запись в таблице может быть только одна. В 1С:предприятие есть такой объект, который называется константа. Он не имеет ничего общего с тем, что под этим обычно подразумевается. Концептуально, константа в 1С — это таблица с одной колонкой и одной строкой. Чисто умозрительно, полезная штука, но на практике — не очень. Эти самые константы надо как-то группировать. Приходится задавать префиксы имен. Имена становятся уродливыми. Регистр сведений без измерений, по сути, представляет собой поименованное множество пар ключ-значение. И это отличная альтернатива константам.
Подчинение регистратору
Регистры сведений входят в семейство регистров 1С. По правде сказать, они не совсем полноправные члены этой семьи. Регистры сведений — это универсальный инструмент, в то время как регистры накопления гораздо более специализированы, а уж регистры бухгалтерии и регистры расчетов специализированы очень сильно. Единственное, что обнаруживает родственную связь регистров сведений с прочими регистрами, это то, что записи в регистрах сведений могут создаваться на основании документов. Здесь же, кстати, можно увидеть и отличие регистров сведений от остальных регистров. Во всех прочих регистрах записи создаются ТОЛЬКО на основании документов, а для регистров сведений этот вопрос оставлен на усмотрение разработчика. В принципе, этим пользуются и в типовых и в нетиповых конфигурациях, но лично я не вижу в этом большого смысла. Здесь имеет место скорее некоторая инерция. Разработчики привыкают использовать связку документ-регистр для регистров накопления, а потом переносят эту практику на регистры сведений.
Регистр сведений с измерением типа дата
Есть такая довольно часто встречающаяся задача, которая называется «Получить последние значения чего-либо». У нее есть известное решение, укладывающееся в три строки SQL запроса. В 1С-овском диалекте это выглядит так:
ВЫБРАТЬ валюта, курс, дата
ИЗ РегистрСведений.КурсыВалют КАК КурсыВалют
ГДЕ дата В (ВЫБРАТЬ МАКСИМУМ(дата) ИЗ КурсыВалют КАК Т ГДЕ Т.Валюта = КурсыВалют.Валюта)Чтобы избавить разработчиков от необходимости вспоминать это решение, в 1С решили сделать так. Регистры сведений, у которых в составе первичного ключа есть дата, были объявлены особенным подвидом и названы периодическими регистрами сведений. У этих периодических регистров сведений появились виртуальные таблицы под названием срез последних. При обращении к этим таблицам происходит выполнение запроса, являющегося аналогом того, что я указал выше. Там, правда, действует странное ограничение. Получить последние значения вы можете только по полному списку измерений. Это противоречит опыту, который разработчики получают при взаимодействии с регистрами накопления. Обращение к виртуальной таблице оборотов регистра накопления возможно по любому подмножеству измерений. Но в целом, периодические регистры сведений — это полезный инструмент. Хотя, в последнее время, с появлением версионирования и истории версий, он несколько утратил свое значение.
Заключение
Сильная сторона 1С в том, что можно не знать многие вещи, например, о базах данных. И при этом создавать работоспособные приложения. В большинстве случаев, вам не требуется знать или помнить в деталях для чего нужны первичные ключи и как они работают. Система все сделает за вас. Но когда вам потребуется сделать что-то из области универсального, тогда начальные знания о том, как это работает, все-таки будут нелишними.
В заключение хочу порекомендовать бесплатный вебинар от OTUS, где преподаватели покажут как решаются задачи проектирования объектов метаданных различных конфигураций, для решения практических задач бизнеса.
-
Подробнее о бесплатном вебинаре
Данная работа является оформлением некоторых размышлений, появившихся при знакомстве
с продуктом «1С:Предприятие 8.0» (далее V8). По своей направленности работа является
в некотором роде продолжением статьи «От V7 к V8. Обсуждение концепций структур
данных» [1] . Часть поднятых в той работе вопросов устарела с выходом V8, часть
осталась, появились и новые.
Небольшое вступление (или отступление)
Как известно, в электронике существует всего два типа проблем – отсутствие
контакта там, где он должен быть и его наличие там, где его быть не должно.
Сходным образом можно сформулировать два типа проблем в программных концепциях:
- Смешение нескольких понятий там, где требуется их разделение;
- Использование различных понятий там, где можно обойтись одним.
Первая проблема обычно приводит к неполному описанию (функциональному покрытию)
предметной области, а вторая – к сложности (запутанности) внутреннего устройства
систем.
Процессы повышения «внутреннего качества» системы обычно называют рефакторингом
и/или нормализацией. « Рефакторинг (Refactoring) (сущ.) представляет
собой процесс такого изменения программной системы, при котором не меняется
ее внешнее поведение, но улучшается внутренняя структура» [2]. Под нормализацией
предметной области (системы) мы понимаем выделение минимального числа независимых понятий
(сущностей, объектов), позволяющих описывать данную область (реализовывать
требования системы) в полном объеме. В данном определении два ключевых слова
«минимального» и «независимых» связаны между собой. Если, все понятия предметной
области независимы, то их количество будет минимально, и, наоборот, при минимизации
количества понятий их взаимосвязанность уменьшается.
Вообще, можно выделить два рода проблемных систем (подсистем). Плохо спроектированные
системы первого рода слабо отвечают заявленной функциональности (например,
ненадежны). Очевидно, что сравнивать качество систем по простоте (сложности)
их внутреннего устройства можно лишь при их сравнимой внешней функциональности.
Поэтому, первый коэффициент качества системы (подсистемы) можно представить
в виде: КК = Функциональность/Сложность.
Подозрительные системы второго рода функциональность отрабатывают, но их трудно
модифицировать. Оглядываясь на развитие программных систем, мы видим, что именно
«простота модификации» является историческим судьей, выносящим приговор той
или иной системе. Для оценки качества программных систем очень важен дифференциальный
КК, показывающий насколько сложно изменить систему: dКК = (∆ функциональности)/(∆
сложности). Разработчик любого коммерческого продукта находится под давлением
необходимости «расширения функциональности продукта в сжатые сроки». Возникает
соблазн пожертвовать ясностью и простотой. Разумеется, такие жертвы допустимы
только до определенного предела, после которого сложность системы не позволяет
наращивать ее функциональность эволюционным путем. Кстати, тот факт, что прямая
преемственность между V7 и V8 отсутствует (V8 не поддерживает конфигурации
V7), говорит о низком значении dКК для V7. Одной из причин этого является то,
что объектная модель V7 является плоской и замкнутой.
Удобство использования и простота модификации, минимизация сущностей и полнота
покрытия потребностей разработчиков конфигураций являлись основными критериями
для оценки «проблемности» того или иного решения, реализованного в V8.
Набор базовых объектов
Платформа «1С:Предприятие» является универсальной учетной платформой. В то
же время согласно классическим учебникам [3], именно учет является одной из
основных задач баз данных. Таким образом, платформу V8 можно отнести к классу
объектно-ориентированных СУБД (ООСУБД), точнее к классу темпоральных (обеспечивающих
работу с динамическими данными) ООСУБД.
Однако при такой классификации (и, соответственно, позиционировании) бросается
в глаза чрезмерная детальность V8 в отношении нескольких частных прикладных
задач. Речь идет, прежде всего, об объектах для решения бухгалтерских и расчетных
задач. Не умаляя их важности, все же отметим, что данные объекты принадлежат
другому уровню, прикладной предметной области. Они нарушают стройность и законченность
фундаментального набора объектов. В каком-то смысле объектная модель V7 была
более логичной: прикладные объекты были вынесены в отдельные компоненты платформы.
Итак, в фундаментальный (базовый) набор хранимых объектов входят: Константы,
Справочники, Документы и Регистры. Все остальные объекты должны строиться на
основе базовых. В идеале – через механизм наследования свойств, но поскольку
V8 является плоской объектной средой, то, значит, через эмуляцию наследования.
Необходимость разделения объектов (фактически классов) по слоям (уровням)
предметной направленности кажется настолько очевидной, что вряд ли здесь требуются
какие-либо доказательства. То, что базового набора достаточно для успешного
решения как бухгалтерских, так и расчетных задач, доказано на практике. А вообще,
о негативных последствиях того, что различные классы объектов выполняют фактически
одно и то же, много говорится, например, в [2]. Помимо неудобств для разработчиков
(имеющих тенденцию возрастать со временем) отметим неудобства для пользователей
в изучении и использовании похожих классов. Все ли их свойства тождественны?
Нет ли каких-либо тонкостей, о которых необходимо постоянно помнить?
Чем различаются, например, накопительный и бухгалтерский регистр? Существует
ли какая-то разница в поведении объекта «План счетов» и обычного справочника?
А если и существует, то достаточна ли она для выделения плана счетов в отдельный
класс? В V7 план счетов отличался тем, что, в отличие от обычного справочника
для него существовала возможность ввода в режиме «Конфигуратор» так называемых
предопределенных элементов (счетов). Но в V8 механизм предопределенных элементов
реализован для любого справочника.
Обобщение предопределенности
Опыт разных команд разработчиков тиражных конфигураций на V7 привел к появлению
понятия «предопределенных элементов справочников» (еще их называют регламентированными
элементами). Это такие элементы, значения (и поведение) которых разработчику
заранее известно (поскольку им же определено). Почему именно «тиражных конфигураций»?
В «заказных» конфигурациях разработчик имеет дело с одной уникальной базой
данных, поэтому для него в некотором смысле все элементы справочников являются
предопределенными. Он имеет возможность произвольного управления свойствами
того или иного элемента. В тиражных же конфигурациях разработчику заранее неизвестно,
какой, например, код присвоят пользователи (или установит государство) бухгалтерскому
счету учета взаиморасчетов с поставщиками. Прописывание в коде строковых констант
(«Если Счет.Код=«60» Тогда…») противоречит всем санитарным нормам
создания программного кода. Зато при наличии механизма предопределенных элементов
можно написать: «Если Счет=Справочники.ПланСчетов. СчетПоставщиков Тогда…».
Красиво, удобно и читаемо.
Попробуем обобщить понятие предопределенности. Прежде всего, отметим, что
теперь тип метаданных «Перечисление» становится излишним, поскольку Перечисление
есть ни что иное, как Справочник, все элементы которого являются предопределенными.
Соответственно, методы и свойства перечислений должны совпадать с методами
и свойствами справочников. Удобство объединения понятий «перечисление» и «справочник»
заключается также в простоте перехода от справочника с жестко определенным
набором элементов к справочнику с расширяемым набором элементов. Такая модификация
может быть востребована в сложных проектах, в которых на начальном этапе разработки
конфигурации не всегда можно уверенно определить, должен ли быть набор элементов
справочника/перечисления доступен для расширения пользователем или нет. Кстати,
в текущей версии V8 отсутствует возможность задавать для предопределенных элементов
справочников значения их реквизитов. Наверное, такая возможность была бы полезной.
Теперь рассмотрим проблему «предопределенных элементов» шире. В процессе разработки
любой тиражной конфигурации разработчики стремятся достичь компромисса между
жесткостью (предопределенностью) и гибкостью (настраиваемостью) ее свойств.
Таким образом, понятие предопределенности можно (нужно) применить ко всем объектам
платформы (конфигурации). Например, упоминаемый выше «План счетов» есть не
что иное, как предопределенный справочник (элемент списка справочников). Другими
кандидатами на предопределенные элементы (группы) данного списка являются справочники
«План видов характеристик» и «План видов расчета». Пригодился бы также регламентированный
справочник «Виды документов» с предопределенным перечнем элементов, совпадающим
с видами документов метаданных. Набор прав (роли) также логично было бы реализовать
в виде регламентированного справочника. Такая реализация даст возможность доопределять
реквизиты, создавать подчиненные справочники и т.д.
Предопределенными также могут быть (точнее являются по умолчанию) модули (код)
тиражной конфигурации, ее переменные, формы, макеты и пр. Перенастраивать предопределенные
элементы (например, менять код) является плохим стилем (возникают проблемы
обновления). Вместо этого необходимо использовать возможности расширения, которые
обычно предоставляются разработчиками для конечных пользователей (к примеру,
добавление внешних модулей, печатных форм и пр.).
Понятие предопределенности распространяется также на реквизиты хранимых объектов
(справочников, документов, регистров). В V8 для возможности расширения предопределенного
набора реквизитов ввели объект «План видов характеристик». Для конечного пользователя
было бы проще (удобнее) работать с понятиями «предопределенные реквизиты» и
«реквизиты, определенные пользователем». При обновлении конфигурации поставкой
разработчика все объекты, которые были определены пользователем, не затрагиваются.
Модификации могут быть подвержены только «предопределенные элементы».
Объектность и подчиненность
Хранимые данные V8 делятся на два типа: ссылочные данные (объекты) и наборы
записей (коллекции). Объектные данные характерны тем, что на них могут ссылаться
другие данные. На элемент набора записей возможность ссылки отсутствует. Объектными
данными являются справочники и документы. Примером набора записей служат табличные
части тех же справочников и документов, данные движения регистров. В V8 наборы
записей всегда подчинены какому-либо объекту (имеют владельца).
Как известно, в V7 справочники не имели табличных частей, зато могли иметь
подчиненные справочники. Табличную часть (правда, всего одну) мог иметь документ.
В V8 возможности справочников расширили (добавили механизм табличных частей,
множественность подчинения), и стала очевидной натянутость разделения сущностей
подчиненный справочник и табличная часть. Во-первых, на начальном этапе разработки
конфигурации не всегда очевидно, какой тип объекта для подчинения (справочник
или табличную часть) следует использовать. Следовательно, при необходимости
модификации подчинения (преобразования табличной части в справочник) могут
возникнуть проблемы. Во-вторых, фактически подчиненный справочник отличается
от табличной части лишь наличием скрытого реквизита (идентификатора объекта
OID), обеспечивающего возможность ссылки на элемент. Во всем остальном их свойства
совпадают (должны совпадать). Например, для табличных частей (как справочников,
так и документов) также бы пригодилась возможность иметь несколько видов владельцев.
В этом случае табличная часть многих видов документов (к примеру, СчетФактураПриход
и СчетФактураРасход) могла быть одним объектом, что опять же удобно при модификации
их свойств.
Таким образом, имеет смысл объединить подчиненные справочники и табличные
части в единый класс (например, ПодчиненнаяКоллекция), а разработчику конфигурации
дать возможность устанавливать/отключать (естественно, соблюдая при этом ссылочную
целостность) свойство «ссылочности» (объектности) элементов коллекции. При
объединении данных сущностей становится единообразным и синтаксис доступа к
элементам подчиненных объектов. То есть свойство справочника (документа) естественным образом перешло бы в свойство , давая доступ к реквизитам ее элементов.
Свойство подчиненности следует распространить и на регистры, точнее на детерминанты
регистров. Данная проблематика требует отдельного раздела.
Регистры и детерминанты
Регистры являются центральным объектом, на котором базируются учетные системы.
Подавляющее большинство всех отчетов в конфигурациях строятся на основе данных
регистров. В [1] показано, что регистры являются реализацией фундаментальной
концепции Функциональной Зависимости. Регистр сведений, введенный в V8, закрыл
определенную брешь в иерархии регистров V7, на которую было указано в [1].
Тем не менее, предложенная в V8 модель регистров не является законченной (недостаточно
покрывает предметную область).
Перечислим несколько проблемных моментов, которые не решаются удовлетворительно
в рамках концепции V8. С устоявшейся терминологией пока туговато, — для набора
измерений регистров мы будем использовать термин детерминант .
Объединение различных типов ресурсов с общим детерминантом
Во многих учетных задачах было бы удобно хранить в одном регистре (для одного
набора измерений) ресурсы различных типов. Часто требуется хранить «состояние
чего-либо», подтвержденное значением накопительного ресурса. Например, в регистре
с детерминантом {#Товар, #Склад} наряду с накопительным ресурсом «Остаток товара»
можно было бы хранить простой ресурс «Планируемая дата поступления». Таким
образом, правильно говорить не о разных типах регистров, а о различных типах
ресурсов – простые, периодические, накопительные остаточные, накопительные
оборотные.
Учет единиц измерения накопительных ресурсов.
Данная проблема уже поднималась в [1]. Проще всего ее пояснить на примере
количественного учета товаров на складах в различных единицах измерения и/или
стоимостного в различных валютах. Один товар может учитываться на складе одновременно
в разных единицах измерения. Очевидно, что суммировать имеет смысл лишь те
ресурсы, которые выражены в одинаковых единицах измерения – штуки со штуками,
килограммы с килограммами, рубли с рублями. Решением представляется введение
понятия подчиненности регистров регистрам (точнее детерминантам регистров).
Тогда ресурсы, требующие единиц измерения, можно будет хранить в подчиненных
регистрах. Для ресурса «Количество» подчиненный регистр будет состоять из измерения
«Единица измерения товара» и непосредственно количественного ресурса. Для ресурса
«Стоимость» подчиненный регистр будет состоять из измерения «Валюта» (ссылка
на соответствующий справочник) и накопительного ресурса «Стоимость».
Справочник или регистр сведений?
Данная проблема отсутствовала в V7, поскольку регистров сведений не существовало,
и выбора не было. V8 же стимулирует пересмотр многих привычных концепций. Простой
вопрос, какая структура данных V8 (объект метаданных) лучше всего подходит
для отражения такого привычного объекта как «Сотрудник»? Поясним, почему выбор
справочника неочевиден. Вообще говоря, сотрудник является ролью, которую исполняет
физ. лицо по отношению к компании, его нанявшей. Для отражения таких связей
двух объектов удобен регистр сведений – в данном случае с детерминантом {#ФизЛицо,
#Фирма} и ресурсами, в которых хранятся атрибуты данной связи. Однако регистр
сведений не является ссылочной сущностью, на такого сотрудника отсутствует
возможность ссылки. Если для учета сотрудников заводить отдельный справочник,
то теряется выделенность реквизитов «ФизЛицо» и «Фирма».
Мы перечислили несколько ситуаций, указывающих на неполное функциональное
покрытие модели регистров V8 существующих потребностей. Указанные проблемы
можно было бы решить через придание детерминанту регистров свойства «ссылочности».
Итак, является ли детерминант регистра быть объектной сущностью? На наш взгляд,
да. Возьмем, к примеру стандартный регистр складского учета с детерминантом
{#Номенклатура, #Склад}. И Номенклатура, и Склад являются объектами (справочниками).
В то же время присутствие данной номенклатуры товара на данном складе означает
и существование нового независимого объекта – . Ресурсы
регистра играют роль реквизитов этой сущности. Таким образом, мы предлагаем
ввести новый объектный тип метаданных – Детерминант. В регистре в качестве
измерения можно указывать ссылку на какой-либо детерминант. Фактически, мы
добавляем дополнительный уровень косвенности в структуры данных. Теперь ссылка
на измерение регистра будет не прямой (Регистр.СкладскойУчет.Товар), а косвенной
(Регистр.СкладскойУчет.Детерминант.Товар). Очевидно, что структура и свойства
детерминанта будут совпадать со свойствами статического регистра сведений без
ресурсов с тем отличием, что будет присутствовать скрытый реквизит OID.
При выполнении движений по регистру, детерминант которого является ссылочным,
система должна проверить существование в таблице детерминанта записи с нужным
набором измерений. При отсутствии таковой соответствующее значение детерминанта
создается. Возможно, что также потребуется хранить в детерминанте «Количество
внешних ссылок» с тем, чтобы при уменьшении их количества до нуля автоматически
удалять данный детерминант из таблицы. То есть провели приход номенклатуры
на склад – количество внешних ссылок на данный детерминант инкрементируем,
отменили проведение – декрементируем и сверяем с нулем.
Отметим также, что косвенность измерений регистра (измерение ссылается на
детерминант) приводит к упрощению модификации их структуры. Добавление нового
измерения в детерминант не требует пересчета итогов регистров, поскольку структура
регистра не меняется.
Объектный (ссылочный) детерминант является удобной структурой для хранения
адресов (указателей) чего-либо. Например, детерминантом могут быть адреса проживания
физ. лиц, поскольку не может быть двух адресов с одними и теми же значениями
набора измерений. Адресом является также дебетовая и/или кредитовая часть бухгалтерской
проводки. Совокупность бухгалтерского счета и набора значений субконто и есть
адрес, на котором необходимо изменить остаток. Следовательно, измерением регистра
остатков, хранящего бухгалтерские итоги, должна быть просто ссылка на детерминант,
в котором бы хранился набор значений счета и субконто. Кстати, одно из преимуществ
такой организации – отсутствие ограничения на количество уровней аналитики.
Набор допустимых видов субконто совпадает с набором измерений детерминанта.
Сколько видов субконто присутствует, — столько и возможных уровней аналитики
на счете.
К ссылочным детерминантам также применимо естественным образом понятие подчиненности.
То есть регистр может иметь детерминант, подчиненный другому детерминанту (решает
проблему учета накопительных ресурсов в разных единицах измерения).
Периодические реквизиты справочников
В V8 для хранения периодических реквизитов справочников предлагается использовать
регистры сведений. Это разумно. Однако теперь обычные (статические) реквизиты
справочника определяются в одном месте (в самом справочнике), а периодические
– в другом (в регистре сведений). И никакой видимой связи между ними. Получается,
что разработчик конфигурации должен помнить, какие реквизиты, где лежат. Очевидно,
что это неудобно. Обычной также является ситуация, когда статический реквизит
становится динамическим. Изменить периодичность реквизита в V8 далеко не так
же просто, как в V7. Было бы неплохо вернуть понятие периодических реквизитов
на уровне семантики. Это было одно из заметных удобств в v7. То, что способ
хранения периодичности кардинально изменился, совсем не означает, что теперь
надо отказаться от самого понятия.
Может быть, имеет смысл использовать для хранения периодических реквизитов
справочника регистр сведений с детерминантом, подчиненным данному справочнику?
Если в детерминанте отсутствуют измерения, а сам регистр – периодический, то
получим обычные периодические реквизиты справочника. В то же время, если в
детерминанте будут присутствовать какие-то дополнительные измерения, то это
будет означать, что для определения значения данного реквизита справочника,
помимо даты нужно что-то еще. Например, в таком регистре можно было бы хранить
реквизит «Адрес» для справочника «Юр. (физ.) лица». А в качестве дополнительного
измерения детерминанта использовать перечисление {«Фактический», «Юридический»}.
Ссылка, Объект, Выборка…
В таблице 1 приведены свойства трех различных объектов для работы с данными
справочников V8: СправочникСсылка, СправочникОбъект, СправочникВыборка (то
же для документов).
|
Свойство |
СправочникСсылка |
СправочникОбъект |
СправочникВыборка |
| + | + | + | |
| + | + | + | |
| Владелец | + | + | + |
| Код | + | + | + |
| Наименование | + | + | + |
| ПометкаУдаления | + | + | + |
| Предопределенный | + | + | + |
| Родитель | + | + | + |
| Ссылка | + | + | + |
| ЭтоГруппа | + | + | + |
| ЭтотОбъект | + |
Таблица 1. Перечень свойств объектов для работы со справочниками
(«+» означает наличие свойства).
Мы видим, что у различных объектов практически одни и те же свойства. Правда,
большинство свойств (но не все) «СправочникОбъект» доступны как для чтения,
так и для записи, а свойства остальных объектов – только для чтения.
Теперь составим аналогичную таблицу для методов данных объектов.
|
Свойство |
СправочникСсылка |
СправочникОбъект |
СправочникВыборка |
| Заблокирован | + | ||
| Заблокировать | + | ||
| Записать | + | ||
| Заполнить | + | ||
| Метаданные | + | + | |
| Модифицированность | + | ||
| ПолноеНаименование | + | + | |
| ПолныйКод | + | + | |
| ПолучитьМакет | + | ||
| ПолучитьОбъект | + | + | |
| ПолучитьФорму | + | + | |
| ПринадлежитЭлементу | + | + | |
| Прочитать | + | ||
| Пустая | + | ||
| Разблокировать | + | ||
| Скопировать | + | + | |
| Следующий | + | ||
| Удалить | + | ||
| Уровень | + | + | |
| УровеньВВыборке | + | ||
| УстановитьНовыйКод | + | ||
| УстановитьПометкуУдаления | + | ||
| ЭтоНовый | + |
Таблица 2. Перечень методов объектов для работы со справочниками
(«+» означает наличие метода).
При взгляде на таблицу 2 возникает много вопросов. Почему при совпадающих
свойствах объектов не обеспечено подобное же совпадение их методов? Почему
бы ни обеспечить трансляцию методов «СправочникОбъект» в «СправочникСсылка»
и «СправочникВыборка»? Ведь и «Ссылка» и «Выборка» имеют метод ПолучитьОбъект(),
то есть возможность добраться до методов объекта существует. Почему-то «Ссылка»
может напрямую ПолучитьФорму(), но не может ПолучитьМакет(). А «Выборка» вообще
ничего напрямую не может. Не просматривается единой логики.
Вообще, возможно, было бы правильней не создавать линейку схожих объектов,
а ввести понятие «состояние объекта» (нормализация!). То есть заявить о том,
что объект «Справочник» (на уровне работы с данными) может иметь несколько
состояний – «Выборка», «Ссылка», «Объект». В соответствии с теорией каждое
состояние характеризуется своим набором свойств, методов, событий. В нашем
случае, поскольку набор свойств каждого состояния практически идентичен, описание
объекта (а, следовательно, его понимание и освоение) значительно бы упростилось.
Для каждого свойства (метода) объекта «Справочник» дополнительно потребовалось
бы лишь указать его специфику для различных состояний объекта. Функция ТипЗначенияСтр(спрОбъект)
возвращала бы всегда «Справочник», а функция СостояниеСтр(спрОбъект) возвращала
бы одно из системных перечислений – «Выборка», «Ссылка», «Объект».
Все перечисленное выше относится также и к объекту метаданных «Документ».
Дата и время
Появление данного раздела вызвано неудовлетворенностью принятого в V8 правила
измерять разницу дат в секундах, необходимостью определять состав даты и пр.
На самом деле разве не странно, что разница между переменными, заданными с
одной точностью (день) измеряется с другой (секунда)? Кого-нибудь интересует,
чему равна разница в секундах между 12 июня и 1 мая? Разработчики V8 пошли
на компромисс (SQL поддерживает формат дата+время), пожертвовав ясностью прикладного
кода.
Что можно предложить в качестве альтернативы? Введение понятия точности для
объектов дата+время (для избежания путаницы назовем такой объект «Отметка времени»).
Причем не одной точности (как это принято для обычных чисел), а двух – левой
и правой. Правая точность идентична точности чисел, — определяет точность объекта
«Отметка времени» справа. То есть, если правая точность «Секунды», то отметка
времени учитывается с точностью до секунды. Если «Минуты» — то до минуты, если
«День» — до дня и т.д. «Левая точность» учитывает относительность временных
привязок. Объект «Отметка времени» всегда задает временной отступ относительно
другой более крупной временной шкалы. Таким образом, если в качестве левой
точности временной отметки указан «Месяц», то такой объект указывает на возможность
применения данной отметки к какому-либо году. Левая точность всегда грубее
правой. Конкретный пример, отметка времени «Март, 8» имеет левую точность «Месяц»,
правую «День». Объекты такого типа позволяют хранить памятные даты. Отметим,
что левая точность «Месяц» подразумевает существование временной шкалы «Год».
Другой пример, «Пятница, 10:00». Левая точность – день недели, правая – минуты.
В объектах данной точности можно хранить время еженедельных совещаний.
Итак, левая точность задает относительность временных отметок. Однако если
ограничиться с левой стороны масштабом – годы, то отметку с такой левой точностью
можно считать абсолютной. Для отметок времени с одинаковой точностью доступна
операция образования временного интервала . Временной интервал является
структурой данных с временными отметками {С, По}. Для временного интервала
должна существовать функция вычисления его длины с заданной точностью. Данная
точность, естественно, не может превышать точности временных отметок, составляющих
интервал.
Заключение
Платформа V8 является замечательным и уникальным продуктом. Надеюсь, что перечисленные
выше замечания и предложения будут способствовать дальнейшему развитию и улучшению
линейки продуктов «1С:Предприятие».
Ссылки
1. «От V7 к W8. Обсуждение концепций структур данных», — Дмитрий Малюгин,
2001.
2. «Рефакторинг. Улучшение существующего кода», — Мартин Фаулер, «Символ»,
2003.
3. «Теория и практика построения баз данных», — Дэвид Крёнке, «Питер», 2003.
Copyright © www.ITland.ru 2002-2003
Только что проскочила тема. В той ветке не удалось поспорить по-существу, поэтому открываю свою. Итак. Лично я — за справочник. Думаю, если бы разработчики платформы имели представление о составном уникальном ключе, им не пришлось бы плодить лишнюю сущность. Ваше мнение.
они имеют представление, именно так и есть в РС
За базАр за «лишнюю сущность» неплохобы ответить. Всмысле чем это она лишняя? Вопрос за то имеют / не имеют представление пока опустим.
ниче не понял пред.ветку не видел 
отреж себе пальцы на ногах, зачем тебе лишние сущности, да ещё и десяток…
Я имел ввиду, что при наличии справочника с возможностью задания составного уникального ключа делает регистры сведений не нужными.
надо было разделить понятие периодического и неперодического регистра нафиг а так с РН — остатки и обороты
Нет пометки удаление, есть измерение ведущее. Индексы для измерений. Нет родителей, кода, наименования,владельца и прочей лабуды. Они для разных целей.
Аналогично. Прочитал только старт этой ветки.
так кто против то? периодичность эмулировать можно, вся конфигурация на справочниках
а нафиг всем справочникам составной ключ?
Такая возможность у вас есть уже сейчас. Называется подчиненный справочник. Уникальный составной ключ? Так вот жеШ он : УИДВладельца + УИДЗаписи.
справочник — уникальный объект, который теоретические не повторяется ( хотя можно реализовать ) регистры — записи, которые можно повторить
По твоей логике должны быть отдельные сущности для справочников с иерархией и справочников без иерархии, справочников подчиненных и не подчиненных. Размер такого дерева конфигурации превысил бы все разумные рамки.
То есть ты за справочник?
Имхо полезная вещь, но по сравнению с РН оборотным, лучше бы сюда добавили итоги для периодического регистра
Стоп… стоп… Перейдем к ваше логике. Все (основные) объекты базы данных суть таблички. Достаточно одного объекта с миллионом методов? Так было бы лучше?
Про всю конфигурацию разговор не идет. Есть смысл разделять сущности: справочники, документы, регистры. Вопрос ставится так. Зачем еще одна сущность — регистр сведений?
Лучше — когда есть сущности необходимые: справочники, документы, регистры. И нет сущностей лишних (регистр сведений).
По сути они и есть. В них не прописаны родители владельцы код или наименование. Регистр хорош еще тем, что его легко удалить, в отличие от справочника, т.к. на него нет ссылок.
почитай для начала книжки из комплекта поставки, может что то прояснится в голове )
Я понимаю, что справочник и объект это разные сущности. Но говорю: то, что называется «регистр сведений» по своей сущности является справочником.
хранятся данные по-разному
25 + Вообщето есть у него уникальный _SimpleKey но вот для чего он, не имею понятия.
Реализуй срез последних на справочнике м.б. тогда ты меня убедишь
Ещераз. Базар о «лишних сущностях» требует обоснования. ЧистоКанкретнаяИМХА. Одна из причин появления РС — проблемы обмена (в РБД, с другими системами …) При изменении любого поля в строке справочника как изменившаяся помечается все строка. Со всеми возможными миллионом реквизитов. С помощью регистров свединий реквизиты, не являющиеся ведущими при обменах можно исключить. Такое себе «вертикальное расщепление» из теории БД.
+ Конечно тоже самое можно реализовать на справочниках. Будут называться «Справочники дополнительных реквизитов». Но вопрос ведь не в названии?
А то что в регистрах может быть больше одного измерения автор слышал?
+ Вкупе с тем что у справочников есть уникальная ссылка и с некоторой штукой, которая называется нормализация БД ?
мало какая ерп может похвастаться такое сущностью как регистры, мои знакомые профи-ораклоиды в чистых СУБД на оракле «рожают» эмуляции подобных таблиц самомтоятельно, т.е. ручками и сетуют «у тебя мол разработчики уже прогнулись — бери и пользуйся» вывод: предлагаю добабавить в голосовалку пункт 4. тс — наркоман
а если к такому справочнику добавить периодность записей(измерение период), то это уже будет мамонт
садись — два. регистр от справочника отличают не индексы, а отсутствие и наличие ссылки
Автор ветки вы работали с 1с77??? У вас в справочниках были периодические реквизиты? У вас были тормоза со справочниками в 1с77?
вот тут шаблон периодических сведений
Регистр от справочника отличается предназначением. В регистре сведений «ссылка» есть, просто она составная.
ссылка — это то, на что можно сослаться. Ты можешь сослаться на запись регистра сведений и поместить ссылку в другой объект? И вообще. Ты правда уверен, что для всех случаев лишнее поле ГУИД (которое есть ссылка справочника) ну просто необходимо? Ты действительно считаешь, что единственный объект, дающий связь «многое ко многим» , является лишним?
Ты понимаешь словосочетание ссылочная целосность? Нормализация БД? Это не ссылка, а измерение для поиска. Удаление данной записи не ведет к краху ссылочной целосности. Понятие ведущее для измерения позволяет каскадно удалять записи вместе с удалением ведущего измерения
Справочник с миллионом реквизитов — плохой справочник.
Вот и в книге знаний говорится, что регистр сведений по своей сути справочник. Полностью согласен.
измерения рс — поля первичного ключа. такчто можно считать рс справочник с составныс ПК для которого нужно самостоятельно написать метод автонумерации. справочник — прикладная сущность, которую можно идентифицировать по простому ПК. + второй Уникалный Ключ — номер; если для всех сущностей требовались бы составные ключи не было бы типа модификатора IDENTITY increment
Почему сразу у всех? У кого-то составной ключ, у кого-то простой. И зачем автоинкремент? Лично меня коды бесят. Зачем их сделали по-умолчанию, да еще так, что без бубна не уберешь? 95 % — код не нужен.
Еще раз. СПРАВОЧНИК. Обязательные свойства справочника: — Имеет один ГУИД — Можно на него ссылаться (размещая его ГУИД) Дополнительные свойства справочника: — может иметь код (доп. ключ, уникальность настраиваемая) — может иметь наименование (доп. неуник. ключ) — может иметь родителя (доп. неуник. ключ) — может иметь владельца (доп. неуник. ключ) — может иметь реквизиты — может иметь табличные части РЕГИСТР СВЕДЕНИЙ. — Не имеет собственного ГУИДа. — На него нельзя ссылаться. — Имеет составной первичный уникальный ключ, зависимый от набора измерений. Дополнительные свойства: — Может иметь измерения (значения, формирующие составной уникальный ключ) — Все данные по нему могут быть зависимы от наличия ведущих измерений — Может устанавливаться регистратором — Может иметь периодичность (поле период + ВТ для среза) — Может иметь ресурсы (= реквизиты, значения которых можно получить по составному ключу) — Может иметь реквизиты (= реквизиты, значения которых нельзя получить по составному ключу) — Не может иметь табличные части По-моему, сложно найти менее похожие объекты У справочника с документом больше общего. Вот бизнес-процесс с документом можно было бы и объединить.. и то различия большие.
Автор просто привык в клюшках эмулировать явно недостающие для функционала регистры справочниками. Почти в каждой 7шной конфе есть куча «виртуальных» справочников, которые никуда не выбираются, а чисто хранят привязки.
(49+) кроме того, неясна суть предложения об объединении. Внести справочник с составным ГУИД-ом? и что с ним делать. Варианта 2: а) на него можно ссылаться б) на него нельзя ссылаться. Вариант (б) точно соответствует текущему регистру. Что за справочник, на который нельзя ссылаться? При чем тут будут код и наименование? К чему крепить таб. часть? Рассмотрим вариант (а). ОК, сделали такой объект. В документе сослались на составной ГУИД (к примеру, из 3х измерений). После чего меняем в записи одно измерение. Составной ключ изменился. Что должно произойти со всеми ссылками? Короче говоря, вся тема — бред.
Хорошо. Поставлю вопрос по-другому. Есть справочники, документы и регистры. К какой группе вы отнесете регистры сведений?
составной FK как-то не кошерно, имхо
ну сделай длину 0 ему и все
Есть уши, носы и пальцы. К какой группы вы отнесете ж*пу?
ж*па — это базовый класс для потомков: уши, нос, пальцы, т.к. согласно идеологии опп все растет из ж.. т.е. из базового класса.
Сразу видно человека который не часто делает длину кода равной 0. Не все, ты про бубен забыл.
Это ты хорошо сказанул. Только аналогия по-справедливости должна быть такой:
код справочника — это встроенный реквизит ПОЛЬЗОВАТЕЛЬСКОЙ идентификации записи таблицы БД. Да можно их убрать и в случае пользовтельской идентификации заводить свой собственный, но код — это системный реквизит и по логике запросы к системному более быстрые, чем к своему
ты со своей веткой нуб и опозорился, теперь отмываться будешь год ибо на тебе уже клеймо — профанчик)
Код не нужен в 95% справочников.
ну ты понимаешь, что мнение и статистика дилетантов всегда не объективны, да
давай уже обсудим альтернативную платформу? я серьезно
+ потому что они, как правило, не подвержены весомымы фактами и высказаны наобум — лишь бы ляпнуть. Такова сттратегия поведения профанов, смирись)
регистры — это утрированная модель многомерного пространтства, где наполнителем оного является не материя, а информация(данные), что тут обсуждать — теорию многомерных пространств сейчас учат на 1-м курсе вышке, кто не учил, тот проходит по сообщению
чем они быстрее то? код реально мало где применим, для обменов с внешними системами и там где код имеет осмысленное значение
ну я например могу предложить альтернативную модель регистров сведений, где скорость на чтения и «срез на каждый день запроса» не проблема, правда эта модель имеет меньшую скорость на запись но где-то это вполне приемлимо
Я так далеко не думал. В принципе, меня нынешняя 1С вполне устраивает. Пусть она несколько аляповата, но базовые принципы — вполне здоровые. Два уровня абстракции. Хороший баланс между физическим и логическим уровнем. Интересно, что тебе не нравится?
невозможность архитектурного расширения базовых вещей, та же иерархия справочников или
ну вот теперь принялся вылизывать попу 1С — это, между прочим, правильный шаг на пути професонализма и очень полезный навык)
Лучше дай еще определение регистрам. Они у тебя такие интересные получаются.
альтернативную иерархию для таблицы справочника сейчас можно сваятть В дсиске запросе СКД(только не так как писала та женщина — гуру СКД) и не надо выть, что тормоза и т.д. на реально больших таблицах работа с иерархией всегда не быстрая и считаеться слабым звеном любой СУБД, хотя некоторые из них все время пытаються отимихировать работу с иерахиями
СКД хороша на отчетах, для логики проведения тоже ее юзать? кстати, сделай условие В ИЕРАРХИИ в ЛЕВОМ СОЕДИНЕНИИ
А как сделать так, чтобы в результате не получилась платформа, с которой только ее автор и будет работать?
сделать это очень просто — нужно быть обыкновенным гением, сожалею)
я уже ответил на этот вопрос в
зануды и критиканы, всё я спать, братцы ))
Сожалеешь, что эта ветка появилась? И поэтому сюда пишешь? В том числе, юморески про регистры?
Тэги: 1С 8
Комментарии доступны только авторизированным пользователям
Регистр сведений по сути своей ближе всего к справочнику.
Однако есть ряд важных отличий, некоторые из которых перечислены ниже.
Во-первых регистр сведений не имеет ссылочной структуры, то есть у его записей нет уникальной ссылки, попросту свойства «Ссылка», поэтому на запись регистра сведений нельзя ссылаться.
Во-вторых регистр сведений имеет назначаемый разработчиком состав ключевых реквизитов, называемых измерениями.
Комбинация ключевых реквизитов однозначно идентифицирует запись, то есть двух или более записей с одинаковыми значениями ключевых реквизитов не может быть по-определению.
То есть, к примеру, в регистре сведений, хранящем информацию о длительности рабочих дней с реквизитами «Дата» и «Длительность», реквизит «Дата» будет ключевых, а «Длительность» нет, поскольку в регистре сведений должна быть только одна запись для каждой даты.
В-третьих возможен режим записи в регистр сведений с подчинением регистратору.
То есть записи в регистр сведений будут выполняться документами и при отмене проведения этих документов в случае автоматического удаления движений эти записи будут удаляться.
И в-четвертых регистр сведений может быть периодическим.
То есть информация в нем может быть различной на разные моменты времени.
Классический пример — это курсы валют, сегодня курс один, завтра курс той же самой валюты может быть другой.
Именно поэтому информацию, меняющуюся во времени, нужно хранить в регистре сведений, поскольку методы работы с регистром сведений позволяют использовать агрегатные таблицы «Срез первых» и «Срез последних», в которых можно получить записи, действующие на заданный момент времени.
Ну и напоследок ответ на вопрос, как осуществлять чтение и запись регистра сведений.
Чтение регистра сведений лучше всего осуществлять с помощью запроса.
Работа с запросами является отдельной темой и в рамках данной статьи не рассматривается.
Однако можно читать записи и без запроса с помощью нескольких методов объекта «РегистрСведенийМенеджер».
Методы «Выбрать» и «ВыбратьПоРегистратору» позволяют получить выборку записей с учетом заданного отбора.
Метод «Получить» позволяет получить одну запись, для которой в параметрах метода передается отбор по всем ключевым реквизитам.
Методы «ПолучитьПервое» и «ПолучитьПоследнее» позволяют получить соответственно первую или последнюю запись периодического регистра сведений, удовлетворяющую заданному в параметрах метода отбору.
Методы «СрезПервых» и «СрезПоследних» позволяют получить соответственно срез первых или последних записей, удовлетворяющих заданному в параметрах метода отбору.
Кроме этих методов есть еще два метода, «СоздатьМенеджерЗаписи» и «СоздатьНаборЗаписей», с помощью которых можно создать соответсвенно объект «РегистрСведенийМенеджерЗаписи» или «РегистрСведенийНаборЗаписей», после чего задать значения всех или некоторых ключевых реквизитов и с помощью метода объекта «Прочитать» выполнить чтение в объект записей из базы, удовлетворяющих присвоенным значениям ключевых реквизитов.
В итоге получаем объект, содержащий нужные нам одну или несколько записей.
Запись же в регистр сведений производится с помощью уже упомянутых методов «СоздатьМенеджерЗаписи» и «СоздатьНаборЗаписей» объекта «РегистрСведенийМенеджер».
Можно либо создать объект, после чего заполнить реквизиты записи или список записей и записать объект с помощью метода «Записать».
Либо создать объект, задать значения всех или некоторых ключевых реквизитов, чтобы с помощью метода объекта «Прочитать» выполнить чтение в объект записей из базы, удовлетворяющих присвоенным значениям ключевых реквизитов, после чего выполнить метод «Очистить», после чего уже выполнить метод «Удалить» или заполнить реквизиты записи или список записей и записать объект с помощью метода «Записать».
Как добавить запись в непериодический независимый регистр сведений?
|
НаборЗаписей = РегистрыСведений.ЗначенияСвойств.СоздатьНаборЗаписей(); НаборЗаписей.Отбор.Номенклатура.Установить(ТекущаяНоменклатура); НаборЗаписей.Отбор.Свойство.Установить(ТекущееСвойство); НоваяЗапись = НаборЗаписей.Добавить(); НоваяЗапись. Номенклатура = ТекущаяНоменклатура; НоваяЗапись.Свойство = ТекущееСвойство; НоваяЗапись.Значение = ТекущееЗначение; НаборЗаписей.Записать(); |
Как считать содержимое непериодического независимого регистра сведений «СобственныеКонтрагенты»?
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
НаборЗаписей = РегистрыСведений.СобственныеКонтрагенты.СоздатьНаборЗаписей(); НаборЗаписей.Прочитать(); // Перебрать записи в цикле… Для Каждого Запись из НаборЗаписей Цикл РегистрКонтрагент = Запись.Контрагент; РегистрВидСвязи = Запись.ВидСвязи; РегистрОбъект = Запись.Объект; КонецЦикла; // … или выгрузить записи в таблицу значений. ТаблицаЗаписей = НаборЗаписей.Выгрузить(); ВЫБРАТЬ * ИЗ РегистрыСведений.СобственныеКонтрагенты |
Как удалить все записи из независимого регистра сведений?
|
НаборЗаписей = РегистрыСведений.ТорговоеОборудование.СоздатьНаборЗаписей(); НаборЗаписей.Записать(); |
Как удалить записи независимого регистра сведений с отбором по конкретной организации?
|
НаборЗаписей = РегистрыСведений.ОбъектыСтроительстваОрганизаций.СоздатьНаборЗаписей(); НаборЗаписей.Отбор.Организация.Установить(УдаляемаяОрганизация); НаборЗаписей.Записать(); |
Как добавить запись в периодический независимый регистр сведений?
|
НаборЗаписей = РегистрыСведений.КурсыВалют.СоздатьНаборЗаписей(); НаборЗаписей.Отбор.Валюта.Установить(ТекущаяВалюта); НаборЗаписей.Отбор.Период.Установить(ТекущаяДата); НовЗапись = НаборЗаписей.Добавить(); НовЗапись.Валюта = ТекущаяВалюта; НовЗапись.Период = ТекущаяДата; НовЗапись.Курс = ТекущийКурс; НовЗапись.Кратность = ТекущаяКратность; НаборЗаписей.Записать(Истина); |
Как прочитать (изменить) записи в периодическом независимом регистре сведений?
|
НаборЗаписей = РегистрыСведений.Валюты.СоздатьНаборЗаписей(); НаборЗаписей.Отбор.Период.Установить(ДатаЗаписи); НаборЗаписей.Прочитать(); Для Каждого Запись Из НаборЗаписей Цикл // Чтение и сообщение данных полей записи. Сообщить(Строка(Запись.Период) + » « + Строка(Запись.Валюта) + » « + Строка(Запись.Курс)); // Изменение данных полей записи. Запись.Курс = 0; КонецЦикла; НаборЗаписей.Записать(); |
Как удалить записи в периодическом независимом регистре сведений?
|
НаборЗаписей = РегистрыСведений.КурсыВалют.СоздатьНаборЗаписей(); НаборЗаписей.Записать(); |
Как в периодическом независимом регистре сведений «КурсыВалют» удалить все записи по валютам с наименованиями «EUR» и «USD», период которых меньше 01 января 2005 года?
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
Запрос = Новый Запрос; Запрос.Текст = «ВЫБРАТЬ | * |ИЗ | РегистрСведений.КурсыВалют КАК КурсыВалют |ГДЕ | (КурсыВалют.Период >= ДАТАВРЕМЯ(2005, 1, 1) | ИЛИ | НЕ(КурсыВалют.Валюта.Наименование ПОДОБНО ««USD»«) | И | НЕ(КурсыВалют.Валюта.Наименование ПОДОБНО ««EUR»«))»; ТаблицаОставляемыхЗаписей = Запрос.Выполнить().Выгрузить(); НаборЗаписей = РегистрыСведений.КурсыВалют.СоздатьНаборЗаписей(); НаборЗаписей.Загрузить(ТаблицаОставляемыхЗаписей); НаборЗаписей.Записать(); |
Как прочитать данные, актуальные на определенную дату, из регистра сведений «Курсы валют» с отбором по нескольким валютам (отбор по измерениям)?
|
Запрос = Новый Запрос; МассивВалют = Новый Массив; МассивВалют.Добавить(Валюта1); МассивВалют.Добавить(Валюта2); Запрос.УстановитьПараметр(«МассивВалют», МассивВалют); Запрос.УстановитьПараметр(«ДатаПолучения», ДатаПолучения); Запрос.Текст = » |ВЫБРАТЬ | ВалютыСрезПоследних.Валюта, | ВалютыСрезПоследних.Курс |ИЗ | РегистрСведений.КурсыВалют.СрезПоследних(&ДатаПолучения, Валюта В (&МассивВалют)) КАК ВалютыСрезПоследних»; ТаблицаКурсов = Запрос.Выполнить().Выгрузить(); |
Как поменять период у записей периодического независимого регистра, соответствующих ряду условий?
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 |
Процедура ЗаменаПериода() Запрос = Новый Запрос; Запрос.Текст = «ВЫБРАТЬ | ОтветственныеЛицаОрганизации.Период, | ОтветственныеЛицаОрганизации.СтруктурнаяЕдиница, | ОтветственныеЛицаОрганизации.ОтветственноеЛицо |ИЗ | РегистрСведений.ОтветственныеЛицаОрганизации КАК ОтветственныеЛицаОрганизации |ГДЕ | ОтветственныеЛицаОрганизации.Период <= ДАТАВРЕМЯ(2005, 1, 1) | И | ОтветственныеЛицаОрганизации.СтруктурнаяЕдиница.Наименование | ПОДОБНО «Групп-Трейдинг» | И | (ОтветственныеЛицаОрганизации.Должность.Наименование ЕСТЬ NULL | ИЛИ | НЕ(ОтветственныеЛицаОрганизации.Должность.Наименование | ПОДОБНО «Продавец» | ИЛИ | ОтветственныеЛицаОрганизации.Должность.Наименование | ПОДОБНО «Кладовщик«))»; Результат = Запрос.Выполнить(); Выборка = Результат.Выбрать(); Запись = РегистрыСведений.ОтветственныеЛицаОрганизации.СоздатьМенеджерЗаписи(); Пока Выборка.Следующий() Цикл Запись.Период = Выборка.Период; Запись.СтруктурнаяЕдиница = Выборка.СтруктурнаяЕдиница; Запись.ОтветственноеЛицо = Выборка.ОтветственноеЛицо; Запись.Прочитать(); Если Запись.Выбран() Тогда Запись.Период = Дата(2004, 1, 1); Запись.Записать(); КонецЕсли; КонецЦикла; КонецПроцедуры; |
Как «сделать периодическим» реквизит уже заполненного справочника?
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
Запрос = Новый Запрос; Запрос.Текст = «ВЫБРАТЬ | &ДатаУстановки КАК Период, | Проекты.Ссылка КАК Проект, | Проекты.Ответственный |ИЗ | Справочник.Проекты КАК Проекты |ГДЕ | (НЕ(Проекты.ЭтоГруппа)) И (НЕ(Проекты.Ответственный = &Ответственный))»; Запрос.УстановитьПараметр(«Ответственный», Справочники.Пользователи.ПустаяСсылка()); Запрос.УстановитьПараметр(«ДатаУстановки», Дата(2000,1,1)); ТаблицаРезультат = Запрос.Выполнить().Выгрузить(); НаборЗаписей = РегистрыСведений.ЗакреплениеПроектов.СоздатьНаборЗаписей(); НаборЗаписей.Загрузить(ТаблицаРезультат); НаборЗаписей.Записать(); |
Как добавить записи в регистр сведений, подчиненный регистратору?
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
НаборЗаписей = РегистрыСведений.ЛимитыВозвратнойТары.СоздатьНаборЗаписей(); НаборЗаписей.Отбор.Регистратор.Установить(ВыбранныйРегистратор); НоваяЗапись = НаборЗаписей.Добавить(); НоваяЗапись.Период = ВыбранныйРегистратор.Дата; НоваяЗапись.Номенклатура = ВыбраннаяНоменклатура; НоваяЗапись.ДоговорКонтрагента = ВыбранныйДоговор; НоваяЗапись.ЛимитПоставщика = 50; НаборЗаписей.Записать(); НаборЗаписей = РегистрыСведений.ЛимитыВозвратнойТары.СоздатьНаборЗаписей(); НаборЗаписей.Отбор.Регистратор.Установить(ВыбранныйРегистратор); НоваяЗапись = НаборЗаписей.Добавить(); НоваяЗапись.Период = ВыбранныйРегистратор.Дата; НоваяЗапись.Номенклатура = ВыбраннаяНоменклатура; НоваяЗапись.ДоговорКонтрагента = ВыбранныйДоговор; НоваяЗапись.ЛимитПокупателю = 25; НаборЗаписей.Записать(Ложь); |
Как прочитать (изменить) записи в регистре сведений, подчиненном регистратору?
|
НаборЗаписей = РегистрыСведений.ЦеныНоменклатуры.СоздатьНаборЗаписей(); НаборЗаписей.Отбор.Регистратор.Установить(ВыбранныйРегистратор); НаборЗаписей.Прочитать(); Для Каждого Запись Из НаборЗаписей Цикл // Чтение и сообщение данных полей записи. Сообщить(Строка(Запись.Период) + » « + Строка(Запись.ТипЦен) +» «+ Строка(Запись.Номенклатура) + » « + Строка(Запись.Цена) + » « + Строка(Запись.ПроцентСкидкиНаценки)); // Изменение данных полей записи. Запись.ПроцентСкидкиНаценки = 0; КонецЦикла; НаборЗаписей.Записать(); |
Как удалить записи из регистра сведений, подчиненного регистратору?
|
Запрос = Новый Запрос; Запрос.Текст = » | ВЫБРАТЬ | ЦеныНоменклатурыКонтрагентов.Регистратор |ИЗ | РегистрСведений.ЦеныНоменклатурыКонтрагентов КАК ЦеныНоменклатурыКонтрагентов»; Результат = Запрос.Выполнить(); Выборка = Результат.Выбрать(); НаборЗаписей = РегистрыСведений.ЦеныНоменклатурыКонтрагентов.СоздатьНаборЗаписей(); Пока Выборка.Следующий() Цикл НаборЗаписей.Отбор.Регистратор.Установить(Выборка.Регистратор); НаборЗаписей.Записать(); КонецЦикла; |
Если Вы хотите больше узнать о программировании в 1С, тогда регистрируйтесь на курс: 1С 8.3 Старт >>>
