Хранение информации, имеющей привязку ко времени
Практически все объекты, поддерживающие возможность добавления новых полей (значений, реквизитов), могут работать с данными типа Дата. Но зачастую предметом хранения является не информация о датах, а другая информация, которая просто должна храниться в привязке ко времени. Например, необходимо помнить, начиная с какого момента времени для таких-то номенклатурных позиций действуют такие-то цены.
Информацию, хранящуюся в привязке ко времени, чаще всего разделяют на содержащую:
·объектные данные,
·необъектные данные.
Использование документов
В задачах хранения объектных данных, привязанных ко времени, речь обычно идет о регистрации неких событий и всего, что с ними связано, например, в хозяйственной жизни предприятия. Чаще всего для хранения такой информации выбираются объекты Документ.
В пользу такого решения говорит функциональность объектов документов, поддерживаемая на уровне платформы «1С:Предприятие»:
·заполнение,
·запись,
·проведение,
·формирование движений по регистрам,
·расположение на оси времени,
·пометка на удаление,
·удаление.
Кроме этого, положительным моментом является возможность решения (средствами платформы) вопросов отображения списков документов, группирования разных видов документов в единой хронологии для общего отображения или для общей обработки и так далее.
Использование периодических регистров сведений
|
|
|
В нашем примере будет необходимо быстро получить ответ, для какого товара в такой-то момент времени действует такая-то цена. Получение этой информации из документов может оказаться неудобным или длительным по времени, потому что данные разных документов могут противоречить друг другу и для определения истины разработчику придется прописать некие алгоритмы.
Использование периодических регистров сведений позволяет в данной ситуации (и подобных ей) достаточно быстро создать решение, большую часть функциональности которого поддерживает сама платформа (рис. 1.34).
Рис.Структура регистра накопления «ЦеныНоменклатуры»
При этом хотелось бы заметить, что в рассмотренном нами примере оба варианта (и использование документов, и использование периодических регистров сведений) для хранения данных, имеющих привязку ко времени, не противоречат друг другу. Они могут «мирно уживаться» в одном решении и обеспечивать каждый свою функциональность. И даже более того, помогают друг другу.
Использование объекта «ХранилищеЗначения»
При решении вопросов хранения информации желательно различать информацию, обеспечивающую основную бизнес-логику решения и другую, вспомогательную информацию. Данные основной бизнес-логики активно используются в учетных и аналитических механизмах. Для них важны такие вопросы, как индексирование, упорядочивание в запросах и выборках, суммирование, поиск и т. п. Вопросам обеспечения хранения этих данных, по сути, посвящена большая часть данной главы.
|
|
|
Данные же вспомогательной информации нужно просто хранить. Все возможное манипулирование этой информацией сводится к операциям записи и чтения. Итак, платформа системы «1С:Предприятие» предоставляет возможность хранения некоторой вспомогательной информации в базе данных посредством полей типа ХранилищеЗначения. Особенностью использования таких полей является то, что база данных «не обязана ничего знать» о природе хранимой там информации. Это могут быть картинки, файлы, таблицы, данные примитивных типов, да что угодно. База данных отвечает лишь за хранение этой информации, не обеспечивая больше никакой функциональности. При этом еще говорят, что тип значения ХранилищеЗначения позволяет хранить значения различных типов в сериализованном виде, то есть в виде, который позволяет записывать данные и восстанавливать их.
Важной особенностью хранилища значений является возможность хранения данных в сжатом виде. Это позволяет существенно сократить размеры базы данных при необходимости хранения больших объемов информации. С прикладной точки зрения в полях типа ХранилищеЗначения можно хранить, например, значения каких-то вспомогательных настроек пользователей, фотографии, изображения, образы файлов и так далее. Например, фотографии сотрудников или файлы с аудиозаписью важных переговоров (то есть данные типа Картинка или ДвоичныеДанные).
|
|
|
При этом, хотя в системе не существует явного ограничения на размер данных, хранящихся в полях типа ХранилищеЗначения, следует все-таки осмотрительно подходить к решению, что именно требуется хранить в базе данных.
Большой объем хранимой вспомогательной информации может привести к тому, что административные операции (например, создание резервной копии базы данных) выполняются медленно из-за большого объема базы данных. А большой объем обусловлен не требованиями обеспечения основной бизнес-логики, а тем, что кто-то из сотрудников решил хранить в базе данных любимые фильмы.
Особенно аккуратно нужно относиться к возможности использования полей типа ХранилищеЗначения в составе объектов (например, справочников, документов), активно использующихся при реализации основной бизнес-логики. Ведь данные объектов считываются целиком при обращении к ним. Поэтому, например, вопрос хранения тех же фотографий лучше решать не в составе справочника Сотрудники, а в отдельном подчиненном справочнике или регистре сведений. Тогда будет сохранена возможность идентификации соответствия изображений сотрудникам, к которым они относятся. И в то же время при использовании объектов справочника Сотрудники для решения других задач выполняемые операции не будут замедляться из-за необходимости считывания из базы данных больших объемов информации.
|
|
|
Дата добавления: 2019-02-22; просмотров: 310; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!