Какую базу данных выбрать 1С — файловую или SQL
В малых и средних организациях обычно перед внедрением 1С раздумывают как выбрать систему баз данных для 1С. Существует два вида этих систем это файловая и SQL. Далее мы расскажем, чем они отличаются и основные их характеристики.
Система управления базой данных часто сокращают как СУБД, делают это для удобства и простоты. 1С совместим с несколькими вариантами систем управления баз данных:
- Файловый (встроенный в 1С)
- MS SQL Server
- Oracle
- IBM DB2
- PostgreSQL
Все из перечисленных СУБД хранят в себе различные функции и уникальные решения.
Файловая СУБД для 1С
Это один из простейших способов установки и внедрения программы 1С. Для это нам не нужно ставить сторонний софт и проводить какие-либо сложные манипуляции. Также большой плюс этого варианта, то что подключаться к базе и работать с ней можно из любой точки земного шара.
Плюсы файловой СУБД 1С:
- Легкость и простота настройки и установки
- Не нужно ничего устанавливать дополнительно
- Низкие вложения средств и мало времени на установку
- Плохая защита и каждый имеет доступ к базе данных
- Плохо работает с большим количеством пользователей, если работает более 6 человек, то начинаются проседания в производительности
- Не все функции функционируют
- Имеет ограниченный размер и не может быть более 12гб
Клиент-серверная вариант системы управления базами данных для 1С на базе SQL
Данный способ отличается отличной безопасностью и надежностью. Также используя клиент-серверный вариант можно использовать базу огромным количеством сотрудников, без каких-либо задержек.
Преимущества 1С SQL:
- Отличная надежность
- Возможность использовать базу данных огромному количеству пользователей
- Нет ограничения по объему базы
- Есть как платные, так и бесплатные СУБД данного типа.
- Нужно поддерживать сервер и обслуживать его
Выводы
Конечно вы должны сами решить какой вариант вам больше подходит. Если у вас крупная компания и большое число сотрудников, то вам нужен клиент-серверный вариант СУБД. А если у вас небольшая фирма и вы не хотите много тратить на внедрение и думаете сделать все быстрее, то ваш выбор файловая СУБД.
Файловая СУБД
Файловая СУБД — одна из систем управления базами данных, которую поддерживает платформа. Файловая СУБД разработана фирмой «1С» и является частью платформы.
Файловая СУБД хранит все данные в одном файле — файловой базе данных. Этот формат хранения данных разработан фирмой «1С» специально для прикладных решений 1С:Предприятия 8.
При создании платформы был необходим эффективный формат для создания на его основе легкого варианта 1С:Предприятия 8 для персонального использования и небольших рабочих групп. Формат должен был удовлетворять определенным требованиям, таким как, эффективность, поддержка UNICODE, возможность размещения всей информационной базы в одном файле. Использование этого варианта не должно было требовать установки дополнительного программного обеспечения у пользователя и каких-либо действий по администрированию.
Должна была обеспечиваться, например, возможность легкого переноса информационной базы на ноутбук или быстрого развертывания удаленного рабочего места на складе. При этом прикладное решение должно было без каких-либо изменений работать как в этом варианте, так и в варианте с использованием сервера баз данных.
По результатам исследования продуктов сторонних производителей и их анализа было принято решение о создании собственного «движка» базы данных, поддерживающего собственный формат хранения.
Техническая реализация работы с файловой базой данных
Файловая СУБД является частью платформы, поэтому при работе системы в файловом варианте толстый и тонкий клиенты самостоятельно осуществляют всю работу с данными.
В случае веб-клиента подключение к файловой базе данных выполняется через веб-сервер, и непосредственную работу с данными выполняет не клиентское приложение, а модуль расширения веб-сервера, который также содержит в себе файловую СУБД.
Взаимодействие элементов системы с файловой базой данных осуществляется по собственному протоколу обмена данными, разработанному фирмой «1С».
Размещение данных 1С:Предприятия 8
Данный документ дает представление о файлах и таблицах баз данных, с которыми работает 1С:Предприятие 8, и о распределении между ними информации, используемой 1С:Предприятием 8. Рассматриваются как файловый, так и клиент-серверный варианты информационных баз.
Приведенная здесь информация предназначена исключительно для понимания расположения и состава данных, используемых 1С:Предприятием, и предназначена для разработчиков прикладных решений и специалистов, занимающихся администрированием информационных баз 1С:Предприятия 8. Приведенная информация не должна использоваться для работы с этими данными какими либо способами, не предусмотренными штатными механизмами 1С:Предприятия 8.
Информационные базы, хранилища конфигураций, вспомогательные данные, временные данные
Предметом данного рассмотрения являются только те данные, которые 1С:Предприятие использует всегда, независимо от действий, исполняемых конкретными конфигурациями, или действий, связанных с выбором пользователем тех или иных файлов. Таким образом, файлы конфигураций, выгрузки данных, внешние обработки и другие файлы, внешние по отношению к 1С:Предприятию 8 здесь рассматриваться не будут.
Данные, которые 1С:Предприятие использует всегда, могут быть разделены на 5 групп в соответствии с их назначением и мерой их ответственности:
- Информационные базы . К информационным базам относится наиболее ответственная информация, включающая: конфигурацию, все данные о хозяйственной деятельности предприятия а также административную информацию. Все данные, относящиеся к информационной базе, объединяются в базу данных. Потеря или искажение каких-то данных информационной базы может привести к потере работоспособности системы, построенной на базе 1С:Предприятия.
- Хранилище конфигурации содержит текущую конфигурацию и историю ее разработки при использовании в Конфигураторе средств групповой разработки. При разработке конфигурации эта информация также является «жизненно важной».
- Журнал регистрации содержит список операций, совершенных над данной информационной базой. Эта информация не является необходимой для работы системы на базе 1С:Предприятия, но может быть важной с организационной точки зрения.
- Вспомогательные данные . К вспомогательным относятся такие данные, которые служат для удобства пользователя и не влияют на логику работы системы на базе 1С:Предприятия.
- Профайлы содержат информацию о расположении окон, текущих позициях, состоянии диалогов и других настройках, позволяющих пользователю работать наиболее комфортно. Различные конфигурации могут хранить в профайлах и другую информацию, которая может быть полезной, но не является необходимой.
- Другие вспомогательные данные . К ним относятся списки информационных баз, зарегистрированных на клиенте или на сервере, и некоторые другие данные.
Размещение данных, принадлежащих разным группам, отличается. Дополнительное разнообразие в способы хранения данных вносит возможность организации как файловых, так и клиент-серверных информационных баз.
Организация информационных баз
Данные, которые определяют логику функционирования системы на базе 1С:Предприятия, относятся к информационной базе. Хранение информационной базы осуществляется в базе данных с виде набора таблиц, для чего 1С:Предприятие 8 может использовать одну из пяти систем управления базами данных (СУБД):
- Встроенную в 1С:Предприятие 8 (файловый вариант информационной базы). В этом случае все данные информационной базы хранятся в файле с именем 1cv8.1cd. Этот файл имеет двоичный формат и по сути является базой данных для встроенной в 1С:Предприятие 8 СУБД.
- Microsoft SQL Server (клиент-серверный вариант информационной базы). Все данные информационной базы хранятся в базе данных Microsoft SQL Server.
- PostgreSQL (клиент-серверный вариант информационной базы). Все данные информационной базы хранятся в базе данных PostgreSQL.
- IBM DB2 (клиент-серверный вариант информационной базы). Все данные информационной базы хранятся в базе данных IBM DB2.
- O racle Database (клиент-серверный вариант информационной базы). Все данные информационной базы хранятся в базе данных Oracle Database.
На уровне объектов базы данных (таблиц, полей, индексов и т. п.) как файловый так и клиент-серверный вариант информационной базы имеют сходный формат (отличающийся несущественными деталями). Некоторая информация об этом формате содержится ниже.
Вся информационная база представляется в базе данных в виде набора таблиц. Среди них есть несколько таблиц, которые обязательно присутствуют в представлении любой информационной базы:
- Config — основная конфигурация информационной базы. Эта конфигурация соответствует реальной структуре данных и используется 1С:Предприятием 8.0 в режиме Предприятия.
- ConfigSave — конфигурация, редактируемая Конфигуратором. Конфигурация из ConfigSave переписывается в Config при выполнении «Обновления конфигурации базы данных» в Конфигураторе, а наоборот — при выполнении в Конфигураторе операции «Конфигурация — Конфигурация базы данных — Вернуться к конфигурации БД».
- Files содержит служебную информацию, например, о работе с хранилищем конфигурации.
- Params содержит параметры информационной базы. Среди них:
- Национальные настройки информационной базы.
- Таблица соответствия объектов метаданных и объектов базы данных (таблиц, полей, индексов).
- Некоторая другая информация.
При старте 1С:Предприятие проверяет наличие в информационной базе перечисленных таблиц и в случае отсутствия какой-нибудь из них выдается сообщение «информационная база разрушена». Отсутствие всех перечисленных таблиц означает, что информационная база пустая. В последнем случае эти таблицы будут созданы.
Перечень и структура других таблиц базы данных определяется конкретной конфигурацией, а именно, определенными в ней объектами метаданных. Имя каждой таблицы состоит из буквенного префикса и следующего за ним номера. Префикс определяет назначение таблицы, а номер позволяет различать таблицы одинакового назначения, относящиеся к разным объектам метаданных. Если в качестве СУБД используется IBM DB2, то описанную структуру имеют не имена таблиц, а их псевдонимы.
Если в конфигурации определен хотя бы один план обмена с установленным флагом «Распределенная информационная база», то будут созданы следующие таблицы:
- _ConfigChangeRec — таблица регистрации изменений объектов конфигурации.
- _ConfigChangeRec_ExtProps — таблица имен файлов измененных внешних свойств объектов конфигурации.
Ниже перечислены различные объекты метаданных, которым могут соответствовать те или иные таблицы.
- Константы
- _Consts содержит текущие значения всех констант, определенных в конфигурации.
- _ConstsChngR — таблица регистрации изменений констант. Создается, если хотя бы одна константа участвует хотя бы в одном плане обмена.
- _Node — таблица плана обмена.
- _Node_VT — табличная часть плана обмена, создается для каждой табличной части.
- _Reference — таблица справочника.
- _Reference_VT — табличная часть справочника — для каждой табличной части.
- _ReferenceChngR — таблица регистрации изменений справочника. Создается, если справочник участвует хотя бы в одном плане обмена.
- _Document — таблица документов для каждого объекта метаданных «документ».
- _Document_VT — табличная часть документа — для каждой табличной части каждого документа.
- _DocumentChngR — таблица регистрации изменений объекта метаданных типа «документ». Создается для каждого объекта метаданных типа «документ», если он участвует хотя бы в одном плане обмена.
- _Seq — таблица регистрации документов — для каждой последовательности.
- _SeqB — таблица границ последовательности — для каждой последовательности.
- _SeqChngR — таблица регистрации изменений последовательности. Создается для каждой последовательности, которая участвует хотя бы в одном плане обмена.
- _DocumentJournal — таблица журнала документов, создается для каждого журнала документов.
- _Enum — таблица перечисления — по одной для каждого перечисления.
- _Chrc — основная таблица плана видов характеристик.
- _Chrc_VT — табличная часть плана видов характеристик — для каждой табличной части.
- _ChrcChngR — таблица регистрации изменений плана видов характеристик. Создается, если план видов характеристик участвует хотя бы в одном плане обмена.
- _Acc — основная таблица плана счетов.
- _Acc_ExtDim — таблица видов субконто плана счетов, создается для плана счетов в том случае, если максимальное количество субконто больше нуля.
- _Acc_VT — табличная часть плана счетов, создается для каждой табличной части плана счетов.
- _AccChngR — таблица регистрации изменений плана счетов. Создается, если план счетов участвует хотя бы в одном плане обмена.
- _CKind — основная таблица плана видов расчета.
- _CKind_BaseCK — таблица базовых видов расчета, создается для плана видов расчета в случае, если его свойство «Зависимость от базы» имеет значение, отличное от «Не зависит».
- _CKind_DisplacedCK — таблица вытесняющих видов расчета, создается для плана видов расчета в случае, если у него установлен флаг «Использует период действия».
- _CKind_LeadingCK — таблица ведущих видов расчета — для каждого плана видов расчета.
- _CKindDN — вспомогательная таблица для порядка вытеснения, создается, если у плана видов расчета установлен флаг «Использует период действия».
- _CKind_VT — табличная часть плана видов расчета, создается для каждой табличной части.
- _CKindChngR — таблица регистрации изменений плана видов расчета. Создается, если план видов расчета участвует хотя бы в одном плане обмена.
- _InfoRg — таблица движений регистра сведений.
- _InfoRChngRg — таблица регистрации изменений регистра сведений. Создается, если регистр сведений участвует хотя бы в одном плане обмена.
- _AccumRg — таблица движений регистра накопления.
- _AccumR g T — таблица итогов регистра накопления, если регистр поддерживает остатки.
- _AccumR g Tn — таблица оборотов регистра накопления, если регистр поддерживает обороты.
- _AccumR g ChngR — таблица регистрации изменений регистра накопления. Создается, если регистр накопления участвует хотя бы в одном плане обмена.
- _AccumRgOpt — таблица настроек хранения итогов регистров накопления одна на все регистры накопления.
- _AccumRgAgg — таблица агрегатов регистра накопления.
- _AccumRgAggOpt — таблица опций сети агрегатов.
- _AccumRgSt — таблица статистики регистра накопления.
- _AccumRgBf — таблица буфера новых оборотов регистра накопления.
- _AccumRgDl — таблица новых оборотов регистра накопления.
- _AccumRgAggDims — таблица кодов измерений регистра накопления.
- _AccumRgAggGrid таблица сети агрегатов
- _AccRg — таблица движений регистра бухгалтерии.
- _AccRgED — таблица значений субконто регистра бухгалтерии, создается в том случае, если он ссылается на план счетов, у которого максимальное количество субконто больше нуля.
- _Acc RgA T0 — таблица итогов по счету.
- _Acc RgA T< i >— где i от 1 до максимального количества субконто. Таблица итогов по счету с количеством видов субконто равным i.
- _AccRgC T — таблица итогов оборотов между счетами, только для регистра бухгалтерии поддерживающего корреспонденцию.
- _AccRgChngR — таблица регистрации изменений регистра бухгалтерии. Создается, если регистр бухгалтерии участвует хотя бы в одном плане обмена.
- _AccRgOpt — таблица настроек хранения итогов одна на все регистры бухгалтерии.
- _CRg — таблица движений регистра расчета.
- _CR g ActP — таблица фактических периодов действия для регистра расчета, создается, если у регистра расчета установлен флаг «Период действия».
- _CRgChnR — таблица регистрации изменений регистра расчета. Создается для каждого регистра расчета, участвующего хотя бы в одном плане обмена.
- _CRgRecalc — таблица перерасчета регистра расчета, создается для каждого перерасчета.
- _CRgRecalcChn g R — таблица регистрации изменений перерасчета. Создается, если перерасчет участвует хотя бы в одном плане обмена.
- _BPRPoint s — таблица точек маршрута бизнес-процесса для каждого бизнес-процесса.
- _BPr — основная таблица бизнес-процесса.
- _BPr_VT — табличная часть бизнес-процесса для каждой табличной части.
- _BPrChngR — таблица регистрации изменений бизнес-процесса. Создается для каждого бизнес-процесса, участвующего хотя бы в одном плане обмена.
- _Task — основная таблица задачи.
- _Task_VT — табличная часть задачи для каждой табличной части.
- _TaskChngR — таблица регистрации изменений в задачах. Создается для каждого объекта метаданных типа «задача», который участвует хотя бы в одном плане обмена.
При использовании IBM DB2 префиксы псевдонимов таблиц начинаются не с символа подчеркивания, а сразу с буквенной части.
Количество этих таблиц зависит от функциональности конфигурации и может быть достаточно большим. В штатном режиме 1С:Предприятие не выполняет проверку их наличия, а также целостности и непротиворечивости содержащихся в них данных. Поэтому важно, чтобы база данных, в которой размещена информационная база 1С:Предприятия 8, была защищена от несанкционированного доступа и ее модификация выполнялась только средствами 1С:Предприятия. Для проверки необходимо использовать функцию «Администрирование — Тестирование и исправление», встроенную в конфигуратор.
Важно также, чтобы резервное копирование и восстановление базы данных, хранящей информационную базу, выполнялось только целиком. С этой целью рекомендуется использование средств резервного копирования баз данных, встроенных в в используемую СУБД. Резервное сохранение файлового варианта информационной базы может быть выполнено копированием файла 1cv8.1cd.
В конфигураторе есть специальная функция: Администрирование — Выгрузить информационную базу. С ее помощью можно выгрузить в указанный файл (файл выгрузки) все данные, относящиеся к информационной базе, и больше никакие. Обратная ей функция «Загрузить информационную базу» позволяет в текущую информационную базу вместо существующих загрузить все данные из файла выгрузки. Эти функции также можно использовать для резервного копирования данных информационной базы как в файловом так и в клиент-серверном варианте.
Хранилище конфигурации
Хранилище конфигурации используется при групповой разработке конфигураций и служит для хранения истории версий конфигурации, включая последнюю (текущую) версию. Все хранилище содержится в одном файле — 1Cv8ddb.1cd , который располагается в каталоге, заданном в качестве каталога хранилища конфигурации.
В процессе разработки конфигураций с использованием средств групповой разработки данные, хранимые в этом файле, являются жизненно важными. Поэтому рекомендуется их резервное копирование.
Журнал регистрации
Журнал регистрации относится к информационной базе и служит для сохранения информации о событиях, возникающих в процессе работы пользователей с данной информационной базой. Эта информация может быть важной с организационной точки зрения, но не является необходимой для функционирования прикладного решения на базе 1С:Предприятия.
Журналы регистрации хранятся в специальных каталогах 1Cv8Log по одному на каждую информационную базу. Каждый каталог содержит файл 1Cv8.lgf и несколько файлов с именами вида yyyyMMddhhmmss.lgp , где yyyy — номер года, MM — номер месяца, dd — номер дня в месяце, hh — номер часа, mm — номер минуты, ss — номер секунды. Например, » 20070525200000.lgp «. Файл 1Cv8.lgf содержит общую информацию журнала регистрации. Каждый файл yyyyMMddhhmmss.lgp содержит фрагмент журнала регистрации за соответствующий период. Имя файла представляет момент времени начала периода. Длина периода определяется настройкой журнала регистрации «Разделять хранение журнала по периодам».
В файловом варианте информационной базы журнал регистрации располагается в каталоге информационной базы, в том же, что и файл самой информационной базы. Например, если информационная база хранится в файле C:/EnterpriseInfoBase/1cv8.1cd, то журнал регистрации будет находиться в каталоге C:/EnterpriseInfoBase/1Cv8log.
В клиент-серверном варианте информационной базы журнал регистрации располагается в подкаталоге рабочего каталога кластера. Имя подкаталога определяется идентификатором информационной базы. Например: «C:/Program Files/1cv82/server/reg_1541/fb9d9cc4-ccd0-4be7-87e8-c5182945291e/1Cv8Log». Подробно о рабочем каталоге центрального сервера и кластера можно прочитать в разделе » Хранение настроек кластера серверов 1С:Предприятия 8 «.
Профайлы
Профайлы содержат информацию, не оказывающую влияния на логику функционирования системы на базе 1С:Предприятия 8. Такая информация не является необходимой, но ее сохранение может, например, повысить комфортность работы пользователя. В профайлах можно хранить формат и расположение окон и диалогов, настройки шрифтов, цветов, отборов и т. п. Потеря такой информации не может привести к нарушению работоспособности системы.
Подробнее назначение профайлов и хранение настроек пользователя описаны в разделе » Сохранение параметров настроек пользователя между сеансами «.
Профайлы различаются по принадлежности хранимой в них информации. Виды профайлов, используемых в 1С:Предприятии 8, представлены в таблице:
Примеры хранимых данных
— Открыто ли табло.
— Настройки текстового редактора./1C/1cv82/1Cv8.pfl, например:
C:/Documents and Settings/User/Application Data/1C/1cv82/1Cv8.pfl— Файлы клиентских настроек, информация о резервных кластерах и другая служебная информация
Например C:\Documents and Settings\All Users\Application Data\1C\1Cv82\1cv8conn.pfl
— Режим аутентификации при старте 1С:Предприятия из отладчика.
— Каталог последнего сохранения хранилища конфигурации в файл.Таблица files базы данных, в которой размешена информационная база.
Информационная база и пользователь
— Настройки динамических списков.
— Настройки отборов по журналу регистрации.Таблица files базы данных, в которой размешена информационная база.
Компьютер и информационная база
— Настройки сравнения файлов конфигураций.
— Настройки глобального поиска по текстам конфигурации./1C/1cv82//1Cv8.pfl, например:
C:/Documents and Settings/User/Application Data/1C/1cv82/ 4129dbdb-b495-41cb-99ea-ef315060a03e/1Cv8.pflКомпьютер, информационная база и пользователь
— Расположение окна синтакс — помощника.
— Список переменных для быстрого просмотра в отладчике./1C/1cv82///1Cv8.pfl, например:
C:/Documents and Settings/User/Application Data/1C/1cv82/ 4129dbdb-b495-41cb-99ea-ef315060a03e/ E8D87DA4-A087-4145-95E7-D613E0F7CB64/1Cv8.pfl1С:Предприятие 8 в режиме Конфигуратора
— Расположение окон конфигуратора.
— Цвета редактора модулей в конфигураторе./1C/1cv82/1Cv8cmn.pfl, например:
C:/Documents and Settings/User/Application Data/1C/1cv82/1Cv8cmn.pfl1С:Предприятие 8 в режиме Конфигуратор и Предприятие
— Расположение некоторых окон (подсказка, отладчик)
— Параменты групповой разработки
— Параметры использования внешних компонент)/1C/1cv82///1Cv8cmn.pfl, например:
C:/Documents and Settings/User/Application Data/1C/1cv82/ 4129dbdb-b495-41cb-99ea-ef315060a03e/ E8D87DA4-A087-4145-95E7-D613E0F7CB64/1Cv8cmn.pflДиалог запуска 1С:Предприятия 8
— Размеры и расположение диалога запуска.
— Настройки диалогов установки параметров информационных баз./1C/1cv82/1Cv8strt.pfl, например:
C:/Documents and Settings/User/Application Data/1C/1cv82/1Cv8strt.pflДанные из профайлов читаются при старте 1С:Предприятия 8 и записываются при его штатном завершении. По этой причине в случае нештатного завершения некоторые пользовательские настройки могут не сохраниться.
Другие вспомогательные данные
Наряду с профайлами в каталоге данных приложения могут содержаться и другие файлы с информацией, сохранение которой делает работу пользователей с 1С:Предприятием 8 более удобной. Среди них:
- def.usr — хранится в каталоге /1C/1Cv8/ (например, C:/Documents and Settings/User/Application Data/1C/1cv82/4129dbdb-b495-41cb-99ea-ef315060a03e/def.usr) и содержит имя пользователя который последним открывал данную информационную базу.
- ibases.v8i — хранится в каталоге /1C/1CEStart (например, C:\Documents and Settings\user\Application Data\1C\1CEStart\ibases.v8i) и содержит список информационных баз, зарегистрированных на данном клиентском компьютере. Этот список отображается в диалоге «Запуск 1С:Предприятия».
- GenTempl_ ru .st, GenTempl_ en .st — стандартный файл шаблонов текста расположен в каталоге загрузочных модулей 1С:Предприятия (например C:/Program Files/1cv82/bin) на русском и английском языке соответсвенно.
- appsrvrs.lst — хранится в каталоге /1C/1cv82 (например, C:/Documents and Settings/User/Local Settings/Application Data/1C/1cv82/appsrvrs.lst) и содержит список серверов 1С:Предприятия, зарегистрированных в утилите администрирования информационных баз в варианте клиент-сервер.
- srvribrg.lst — хранится на центральном сервере кластера в каталоге (например, C:/Program Files/1cv82/server/srvribrg.lst) и содержит список кластеров, зарегистрированных на данном компьютере сервера 1С:Предприятия. Содержащиеся в нем данные необходимы для нормальной работы приложений, использующих данный сервер 1С:Предприятия.
- 1CV8Reg.lst — файл настройки кластера( например C:\Program Files\1cv82\srvinfo\reg_1541\1CV8Reg.lst)
- В каталогах DBNameCache , ConfigSave , Config , SICache хранится множество файлов, кеширующих различные компоненты конфигурации. Эта информация является производной от конфигурации информационной базы, хранимой в базе данных, и служит для ускорения запуска клиентских приложений и повышения их производительности. Кеш конфигурации располагается в каталоге данных приложений текущего пользователя, например, C:/Documents and Settings/User/Local Settings/Application Data/1C/1cv82/7b0a6294-d6a3-41c5-a23e-dc9e5301ad22/DBNameCache.
- В каталоге 1Cv8FTxt хранятся данные, используемые службой полнотекстового поиска. Они располагаются на компьютере центрального сервера 1С:Предприятия в каталоге /. Например: C:/Program Files/1cv82/server/reg_1541/7eac7609-c0cb-4701-83cf-9ff5f8961de8/1Cv8FTxt.
- Группа файлов CACHE/ddb.snp хранится в каталоге хранилища конфигурации и служит для кэширования запрошенных версий конфигурации из этого хранилища. Наличие этих файлов не является обязательным и позволяет ускорить получение версий конфигурации.
- *.1ccr — конфигурационный файл Web-сервиса для работы с удаленным хранилищем может иметь произвольное имя (расширение 1ccr обязательно), формат XML и содержит единственный узел с произвольным именем и атрибутом connectString — в этом атрибуте указывается адрес сервера хранилища в схеме tcp.
- *.mft — файл с расширение mft является файлом-манифестом — специальным файлом, описывающим шаблон конфигурации. Файл может иметь произвольное имя. Файл располагается в каталоге установленного шаблона конфигурации.
- *.v8i — в данном файле приводится описание формата файла описаний зарегистрированных информационных баз. Данный список используют все клиенты. Файл располагается на локальном компьютере в каталоге %APPDATA%\1C\1CEStart\ и по умолчанию имеет имя ibases.v8i.
- 1CESCmn.cfg — файл 1CESCmn.cfg содержит общие настройки программ запуска (1CEStart.exe и 1Cv8s.exe).
- 1CEStart.cfg — файл 1CEStart.cfg содержит настройки, которые используют программы запуска (1CEStart.exe и 1Cv8s.exe) и клиентские приложения (1Cv8.exe и 1Cv8c.exe). Файл расположен в каталоге %APPDATA%\1C\1CEStart.
- adminstall.cfg — файл adminstall.cfg указывает на то, что установка системы программ «1С:Предприятие» выполнялась с использованием средств администрирования операционной системы. Файл располагается в каталоге конфигурационных файлов системы «1С:Предприятие» и представляет собой текстовый документ в кодировке UTF-8.
- comcntrcfg.xml — файл comcntrcfg.xml служит для указания внешнему соединению необходимости запуска в отладочном режиме.
- Файл располагается в каталоге конфигурационных файлов системы «1С:Предприятие», и его наличие не является обязательным.
- conf.cfg — файл conf.cfg определяет расположение каталога общих конфигурационных файлов. Файл расположен в каталоге bin\conf каталога конкретной версии «1С:Предприятия» и представляет собой текстовый документ в кодировке UTF-8.
- debugcfg.xml — файл debugcfg.xml предназначен для настройки дополнительного диапазона портов, используемого при отладке конфигураций. Файл располагается в каталоге конфигурационных файлов системы «1С:Предприятие», и его наличие не является обязательным.
- def.usr — файл хранится в каталоге %APPDATA%\1C\1Cv82\ и содержит имя пользователя который последним открывал данную информационную базу.
- default.vrd — данный файл служит для настройки веб-клиента и использования Web-сервисов, и находится в каталоге виртуального приложения.
- inetcfg.xml — файл inetcfg.xml позволяет задавать настройки прокси по умолчанию и имеет больший приоритет над настройками прокси по умолчанию в Windows. Файл располагается в каталоге конфигурационных файлов системы «1С:Предприятие», и его наличие не является обязательным.
- logcfg.xml — файл logcfg.xml служит для настройки технологического журнала. Файл располагается в каталоге конфигурационных файлов системы «1С:Предприятие», и его наличие не является обязательным.
- logui.txt — располагается в каталоге %APPDATA%\1C\1Cv82\ и содержит список интерактивных действий пользователя, которые выполнялись за время журналирования.
- nethasp.ini — для настройки параметров взаимодействия системы «1С:Предприятие» с HASP License Manager используется конфигурационный файл nethasp.ini. Файл располагается в каталоге конфигурационных файлов системы «1С:Предприятие», и его наличие не является обязательным.
- nhsrv.ini — некоторые настройки HASP License Manager могут задаваться при помощи файла конфигурации nhsrv.ini. При запуске HASP License Manager осуществляет поиск конфигурационного файла nhsrv.ini в различных каталогах в следующей последовательности:
- каталог, в котором размещается исполняемый файл HASP License Manager;
- текущий каталог Windows;
- системный каталог Microsoft Windows (%SystemRoot%\system32 — для 32-разрядной версии и %SystemRoot%\system — для 64-разрядной версии);
- каталог Microsoft Windows;
- каталоги, перечисленные в переменной окружения PATH (только в случае установки HASP License Manager как приложения Microsoft Windows).
Рекомендуется размещать файл nhsrv.ini, если это необходимо, в каталоге, в котором размещается исполняемый файл HASP License Manager. Проверка того, что HASP License Manager нашел и прочитал файл конфигурации, можно с помощью журнала Activity Log/Server Activity Log.
- srv1cv82 — конфигурационный файл /etc/sysconfig/srv1cv82 используется для задания параметров запуска агента сервера «1С:Предприятие» с помощью скрипта /etc/init.d/srv1cv82. Данный конфигурационный файл используется в случае запуска сервера «1С:Предприятия» в операционной системе Linux.
- swpuser.ini — для того чтобы рабочий процесс запускался не от имени того же пользователя, что и агент сервера, в каталоге данных приложений, относящемся к пользователю агента сервера, может быть размещен файл swpuser.ini
- * .lic — лицензии базовых конфигураций (C:\Documents and Settings\All Users\Application Data\1C\licenses)
Файлы программных лицензий расположены в каталоге конфигурационных файлов системы «1С:Предприятие».
Временные данные
Временные данные нужны только в течение нескольких пересекающихся во времени или одного сеанса 1С:Предприятия.
К нескольким пересекающимся во времени сеансам относятся данные совместного использования, которые относятся к файловой информационной базе в целом и нужны, в частности, для реализации блокировок данных информационной базы. Такие данные хранятся в том же каталоге, что и файл информационной базы.
- Файл 1Cv8cl является носителем блокировок объектов базы данных, расположенной в файле .
- Файл 1Cv8Tmp.1cd хранит служебную сеансовую информацию, в частности список активных пользователей.
- Файл 1Cv8Tmp.1cl является носителем блокировок данных, расположенных в файле 1Cv8Tmp.1cd.
Для хранилища конфигурации 1С:Предприятие 8.0 в режиме Конфигуратора создает временные файлы аналогичного назначения, расположенные в каталоге хранилища конфигурации:
- Файл 1Cv8ddb.1cl является носителем блокировок данных из хранилища конфигурации.
- Файл 1Cv8dtmp.1cd хранит служебную сеансовую информацию, в частности список активных пользователей хранилища конфигурации.
- Файл 1Cv8dtmp.1cl является носителем блокировок данных, расположенных в файле 1Cv8ddb.1cd.
Данные, используемые только в течение одного сеанса 1С:Предприятия, размещаются во временных файлах, создаваемых в каталоге, определенном в системе Microsoft Windows как каталог временных файлов. При этом для клиентского приложения используется каталог временных файлов текущего пользователя Windows, например, C:\Documents and Settings\User\Local Settings\Temp. Для сервера 1С:Предприятия используется или системный каталог временных файлов или каталог данных приложений пользователя, от имени которого запускаются рабочие процесса сервера 1С:Предприятия, например, C:\WINNT\Temp.
Как мы в 1С работаем с различными СУБД, не привлекая внимания санитаров (зачеркнуто) разработчиков
Чем большее количество СУБД и ОС поддерживает какая-либо программа – тем больше у нее пользователей, и это хорошо для производителей программы. При этом нужно помнить, что поддержка каждой СУБД – это расходы на разработку и тестирование, и эти расходы хорошо бы минимизировать.
В этой статье мы расскажем о том, как нам удалось написать технологическую платформу, которая способна без изменения кода бизнес-приложения работать с самыми часто используемыми в бизнесе/организациях СУБД.
О том, как мы работаем без изменения кода бизнес-приложения на разных ОС – тут, с различными браузерами — тут, а как на разных мобильных ОС – здесь.
Для тех, кто не в теме 1С — короткий ликбез о технологической платформе 1С:Предприятие. Платформа 1С:Предприятие – это среда быстрой разработки бизнес-приложений. Мы старались спроектировать платформу так, чтобы разработчик бизнес-приложений (в терминологии 1С — прикладной разработчик) как можно меньше думал о том, на какой ОС и СУБД работает его код, да и в целом меньше думал именно о технических деталях, а сосредоточился на бизнес-задачах (подробнее об этом здесь).
Поэтому прикладной разработчик в 1С:Предприятии работает с прикладными же объектами (справочниками, документами, планами счетов и т.д.), не беспокоясь о том, как обеспечить их хранение в базе данных. Почему мы выбрали такой подход – написано в статье «Как мы в 1С:Предприятии работаем с моделями данных, или Почему мы не работаем с таблицами». А ещё необходимо обеспечить целостность и непротиворечивость данных. Т.к. работа может вестись под разными операционными системами, или у заказчиков могут быть установлены свои СУБД, то необходима поддержка наиболее распространенных СУБД. И данные из одной СУБД должны без проблем переноситься в другую.
Уже упомянутый прикладной разработчик сам создаёт объекты в приложении (конфигурации в терминах 1С:Предприятия):
У многих типов прикладных объектов можно добавлять реквизиты для хранения свойств этих объектов (которые являются отражением свойств объектов из реального мира – например наименования у товара). Наиболее близкий аналог реквизита – поле/свойство класса (property, field) в традиционных ООП-языках.
Платформа же сама создаст для этих объектов таблицы и обеспечит связи между этими таблицами. От прикладного разработчика скрыта вся «магия» конкретной СУБД и особенности синтаксиса её языка. Чаще всего разработка конфигурации ведётся в одной СУБД, а непосредственная работа с ней – в другой. Если конфигурация окажется успешной и будет установлена у большого числа пользователей, она может работать с такими СУБД, о которых прикладной разработчик даже не думал при её создании. Все сложности берет на себя платформа 1С:Предприятие.
Какие СУБД поддерживает 1С:Предпрятие?
В качестве «рабочей» СУБД, где хранятся бизнес-данные – четыре самые распространенные промышленные СУБД:
- Microsoft SQL Server
- PostgreSQL
- Oracle Database
- IBM DB2
Также существует собственный формат файловой базы данных 1С, предназначенный для работы небольшого числа пользователей.
Ещё есть Дата акселератор – in-memory СУБД нашей собственной разработки, которая хранит все данные в оперативной памяти (в нее копируются данные из рабочей СУБД) и сильно помогает при выполнении сложных аналитических отчетов, иногда ускоряя их выполнение на порядки.
При необходимости можно обратиться из конфигурации к любой другой СУБД, имеющей ODBC-драйвер, через механизм внешних источников данных.
Посмотрим на примере. Надо реализовать в приложении сущность «Товар» с подчиненной сущностью один-ко-многим «Дополнительные реквизиты». И уметь оперировать со списком товаров.
Наш любимый прикладной разработчик выбрал для реализации требования прикладной объект Справочник, позволяющий хранить данные, имеющие одинаковую структуру и списочный характер. Справочник также позволяет для каждого элемента справочника хранить некоторый набор информации, которая одинакова по своей структуре, но различна по количеству, для разных элементов справочника. Для этого у справочника есть подчиненные сущности – табличные части.
И прикладной разработчик создал справочник Товары с табличной частью ДополнительныеСвойства.
Если загрузить эту конфигурацию на разные СУБД, то видны отличия в наименованиях колонок.
Например, в MS SQL и PostgreSQL используется подчеркивание («_») в качестве первого символа.
В Oracle Database своя специфика:
А в IBM DB2 каждое текстовое поле дополнено ещё одним, с постфиксом «U» — там хранятся строки в верхнем регистре, т.к. IBM DB2 может выполнять только регистрозависимый поиск.
Кроме того, в IBM DB2 при работе с 1С:Предприятием используются не таблицы, а их так называемые алиасы, сами же таблицы имеют достаточно замысловатые имена.
Видите, сколько особенностей необходимо учесть? Но прикладному разработчику требуется не больше минуты, чтобы создать такую структуру в любой из поддерживаемых платформой СУБД. Особо хочется подчеркнуть, что прикладной разработчик не заботится о том, на какой конкретно СУБД будет создана структура для хранения данных и будут выполняться запросы на добавление, извлечение, обновление и удаление информации – всё за него сделает платформа «под капотом». Платформа 1С:Предприятие – не единственный фреймворк, обеспечивающий работу с разными СУБД, но один из немногих, обеспечивающий переносимость приложений между разными СУБД без модификации прикладного кода.
To ORM or not to ORM?
Опытный программист тут же скажет, что есть технология ORM (Object-Relational Mapping), обеспечивающая разработку в терминах классов, а не в терминах таблиц базы данных. И будет прав. Эта технология избавляет разработчика от необходимости писать запросы к базе данных и позволяет манипулировать только объектами. Тем более, что уже есть много готовых реализаций этой технологии. Например, для одной только Java:
Вот так примерно будет выглядеть реализация нашего справочника товаров на Hibernate. Мы создаем объект Товар и объект «Строка таблицы 1». Описываем с помощью аннотаций имена таблиц, для каждого класса – своя таблица. Также указываем, какие поля в каких колонках таблицы хранятся. И не забываем про связи между классами, которые потом превратятся в связи между таблицами.
В случае платформы 1С:Предприятие использовать классический ORM не получится, т.к. ORM компилируется вместе с исходным кодом приложения, разработка же конфигураций идет на встроенном языке 1С.
Как правило ORM поддерживают несколько СУБД. Но разработать с помощью ORM приложение, полностью нейтральное по отношению к типу СУБД, почти нереально. В частности, язык запросов ORM довольно прямолинейно транслируется в SQL. При этом, конечно, учитываются некоторые синтаксические детали диалекта SQL конкретной СУБД, но не более. Образно говоря, через языки запросов ORM «протекают» особенности конкретных СУБД.
И как ещё один аргумент против использования концепции Object-Relational Mapping для наших задач, стоит упомянуть, что прикладные разработчики на 1С пишут свои SQL-подобные запросы для доступа к данным.
Учтя всё вышеперечисленное, мы поняли, что для решения наших задач надо писать свой собственный ORM, и даже нечто большее, чем просто ORM. Что мы, в итоге, и сделали.
Язык запросов SDBL
Мы уже видели, что бывают случаи, когда одно свойство объекта преобразуется в два поля. Но бывают ещё и ситуации, когда один объект может состоять из нескольких таблиц. Например, есть прикладной объект «Регистр накопления», составляющий основу механизма учета движения средств (финансов, товаров, материалов и т. д.), который позволяет автоматизировать такие направления, как складской учет, взаиморасчеты, планирование.
Информация в регистре накопления хранится в виде записей, каждая из которых содержит значения измерений и соответствующие им значения ресурсов. Измерения описывают разрезы, в которых хранится информация, а в ресурсах регистра накапливаются нужные числовые данные. Также каждая запись хранит дату (она заполняется платформой автоматически из текущей даты, но прикладной разработчик может её переопределить).
Типичный пример использования регистра накопления – учет товарных запасов. Такой регистр будет содержать единственное измерение Товары и один ресурс – остаток товара. Можно добавить ещё одно измерение – Склад, и тогда мы сможем анализировать информацию не только по остаткам каждого товара в целом, но и по остаткам товаров на каждом складе.
Регистр накопления автоматически рассчитывает итоги по заданным промежуткам времени, что позволяет быстро составлять отчеты. Для реализации регистра накопления в базе данных создаются три таблицы:
- Таблица движений (пришло/ушло в нашем случае товаров)
- Таблица настроек хранения итогов регистров накопления (до какого момента рассчитаны итоги)
- Таблица итогов по периодам времени
Также необходимо избежать потери данных при изменении объекта в конфигурации (например, добавление новых измерений и/или ресурсов или переименование или изменение типов существующих) и миграции на эту новую, измененную версию конфигурации.
Для решения вышеуказанных проблем нами был разработан специальный язык, который мы так и назвали — Special Database Language (SDBL). Это «промежуточный» язык для работы с данными. Любое взаимодействие с базой данных в платформе 1С:Предприятие происходит только через него – все запросы из встроенного языка 1С, все служебные запросы платформы, любая модификация данных объектов выполняются путем выполнения SDBL-запроса.
Например, прикладной разработчик пишет простой запрос к справочнику товаров для получения наименования и вида товара. Этот запрос транслируется платформой в язык SDBL, а затем запрос SDBL транслируется в запрос к конкретной СУБД:
Здесь – более сложный случай, когда разработчик хочет записать новый объект. Платформа автоматически присвоит объекту новый код (для чего найдет запросом максимальный код в справочнике), а затем выполнит вставку объекта в таблицу.
Как можно видеть, на уровне SDBL мы сразу описываем данные объекта и его табличной части. В итоге один запрос SDBL распадается на несколько запросов к СУБД: сначала – вставка в таблицу товаров, затем – вставка в таблицу единиц измерения, и в конце – проверка версии объекта для обеспечения согласованности данных.
Язык SDBL используется также в исходном коде платформы, что позволяет и в платформе писать СУБД-независимый код. В коде на С++ вся работа с данными идет только через SDBL. Например, мы хотим установить прикладному объекту новый код. Для этого в коде платформы формируется текст SDBL-запроса для поиска максимального существующего кода. Затем выполняется запуск этого запроса, который исполняется уже на конкретной СУБД:
А вот как установка нового кода работает на разных СУБД:
Синтаксис самого SQL – стандартный, но в случае каждой СУБД есть нюансы, и чем запрос сложнее – тем их больше.
Давайте посмотрим внутрь. Единицей исполнения SDBL является пакет. Пакет содержит один или несколько операторов SDBL. Существуют два вида пакетов:
- Определения данных
- Управления данными
Пакет определения данных
Пакет определения данных может содержать операторы:
- CREATE
- DROP
- RENAME
- REMOVE
- SET_GENERATION
- GET_NGENERATIONS
- RESTORE
Например, нам нужно создать два справочника – Организации и Склады.
Для этого будет сформирован пакет SDBL, в котором описывается структура новых объектов и их индексов. Остальные операторы относятся к механизму реструктуризации. Механизм реструктуризации предназначен для миграции на новую версию конфигурации, если новая версия содержит изменения структуры прикладных объектов, и, как следствие, изменение структуры базы данных, подробнее про него будет ниже по тексту.
Пакет управления данными
Пакет управления данными может содержать операторы
Пример запроса 1С:
SQL-запрос для MS SQL Server:
Трансляция и оптимизация
Любое взаимодействие платформы с базой данных превращается в пакет SDBL. Затем этот пакет транслируется в диалект SQL для конкретной СУБД.
Под понятием трансляции пакета SDBL в диалект SQL скрыт большой и сложный механизм. Помимо собственно трансляции происходит оптимизация SDBL-запроса, добавление ограничений доступа для пользователя на уровне записей, если такие ограничения определены в конфигурации (Row-Level Security, RLS) и много другого. В конечном случае получается, что если нам необходимо поддержать ещё одну СУБД, то достаточно написать транслятор SDBL-запроса в диалект SQL этой СУБД.
Ещё одно преимущество SDBL – быстрая оптимизация запросов для каждой поддерживаемой СУБД. На примере ниже – реальный случай, когда служебный запрос платформы к остаткам регистра накопления (порожденный запросом из конкретной конфигурации) был неоптимальным на MS SQL. Неоптимальность заключалась в использовании оператора ИЛИ (OR) в секции условия отбора запроса.
Запрос и его план на тестовой базе выглядел так:
В итоге для того, чтобы выбрать около 2000 строк, запросу приходилось читать с диска почти 700 000 строк. Для оптимизации этого запроса было изменено условие отбора – оператор ИЛИ был заменен на операторы И НЕ.
Условие отбора был изменено внутри платформы в SDBL-запросе, таким образом, эта оптимизация будет применена для всех поддерживаемых СУБД.
Как мы видим – количество прочтенных строк сократилось более чем в 10 раз:
Реструктуризация данных
Прикладные разработчики могут в ходе разработки новых версий конфигураций менять структуру существующих объектов, добавлять новые объекты, удалять старые. При миграции на новую версию конфигурации некоторые такие изменения могут привести к нарушению целостности данных или даже к потере данных. Чтобы избежать таких проблем существует механизм реструктуризации, который также работает через SDBL.
Работает механизм реструктуризации примерно так:
Давайте попробуем разобраться в этом нагромождении окошек и стрелочек.
Итак, у товара (точнее, у прикладного объекта-справочника Товар) есть реквизит ВладелецТовара. Серым цветом выделено его текущее состояние. Этот реквизит имеет составной тип данных и может принимать значение типа Организация или Склад. В схеме SDBL он описан как реквизит составного типа.
В ходе разработки новой версии было принято решение что владельцем товара может быть только организация. Прикладной разработчик изменил тип реквизита. Теперь реквизит ВладелецТовара – не составной и ссылается только на справочник Организации.
После нажатия кнопки «Обновить конфигурацию базы данных» создается новое поколение таблицы товаров с помощью оператора SDBL “CREATE NEW GENERATION”, где реквизит ВладелецТовара уже не составной и является ссылкой на таблицу организаций. При этом в СУБД «лишние» колонки, которые предназначались для составного типа, помечаются постфиксами «_OO». Пользователю выдается предупреждение об изменении структуры справочника Товары. Если владельцем хотя бы одного товара был склад, то пользователь увидел бы ошибку, сообщающую, что реструктуризация не может быть выполнена, так как это приведет к потере данных, и изменения структуры данных не могут быть применены. Такое поведение платформы – защита от потери данных. В такой ситуации пользователь может найти все товары, владельцем которых является склад, и сознательно заменить владельца на нужную организацию. Но в целом при разработке конфигураций мы стараемся избегать таких изменений.
А в случае отказа от принятия изменений механизм реструктуризации выполнит команду SDBL “ROLLBACK” и вернет конфигурацию базы данных в прежнее состояние.
Если же изменения будут приняты, как показано на иллюстрации выше, то будет выполнен оператор «COMMIT» и база данных переключится на новое поколение, т.е. будут удалены «лишние» колонки таблицы товаров и реквизит ВладелецТовара изменит свой тип.
Внешние источники данных
А ещё через механизм внешних источников данных в конфигурации можно получить данные из любой ODBC-совместимой СУБД. Например, есть таблица работников в СУБД SQLite:
Для доступа к ней из 1С создаём внешний источник данных, пишем строку подключения к базе, выбираем таблицы и поля, нужные нам, и с помощью языка запросов 1С:Предприятия читаем данные:
Эта функциональность также работает через SDBL по знакомой нам схеме. Сначала запрос 1С преобразуется в SDBL, а затем – в запрос к конкретной используемой СУБД.
Транзакции в СУБД
Отдельно стоит упомянуть про такую большую тему, как блокировки данных и уровни изоляции транзакций. Каждая СУБД в этом плане ведёт себя по-разному. Где-то конкурентный доступ к данным управляется на уровне блокировок, когда одна транзакция блокирует работу с данными и другие транзакции в это время не могут работать с этими данными. В других СУБД используется версионный режим, когда перед началом транзакции делается копия данных, и другие транзакции получают данные из этого снимка, пока исходная транзакция не завершится.
Платформа 1С:Предприятие может использовать собственные так называемые управляемые блокировки данных.
Однако с точки зрения прикладного разработчика (да и разработчиков платформы) всё прозрачно – пишутся запросы (прикладным разработчиком на языке запросов 1С, разработчиком платформы – на SDBL). Ну а в случае необходимости у прикладного есть возможность самому управлять блокировками данных в тех случаях, когда бизнес-логика требует согласованного и целостного чтения данных в транзакции.
А транслятор для конкретной СУБД сам понимает, как управлять целостностью данных в транзакции.
- Блог компании 1С
- Анализ и проектирование систем
- Хранение данных
- 1С