Как 1с работает с sql

Как мы в 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С

Как 1с работает с sql

1С умеет работать в двух режимах – файловом и серверном. При серверном варианте база данных находится не в файле, а в СУБД на сервере.

СУБД (SQL) – это система управления базами данных. Устно часто называют как «эс-ку-эль» или «скуль» или «сиквел». С 1С используются такие СУБД как MS SQL, Postgre SQL, Oracle.

Подробнее про серверный вариант работы Вы можете прочитать в уроке про сервер 1С. А здесь мы обсудим использование 1С с SQL.

Что такое SQL 1С

База данных – это набор таблиц (каждая табличка как одна страничка в Excel), в которых можно хранить данные.

Язык SQL – это способ запроса данных из этих таблиц. Язык SQL стандартизирован и практически одинаков во всех современных СУБД. Язык запросов 1С также является одним из вариантов реализации языка SQL.

СУБД – это комплекс программ и драйверов. Функции СУБД заключаются в том, чтобы самостоятельно организовать базу данных тем способом, который ей нравится (в некоторых СУБД база данных — это файл, в некоторых – раздел на диске с самостоятельной файловой системой) и обеспечить доступ к данным с помощью запросов на языке SQL.

В файловом варианте база данных 1С хранится в файле на диске и для доступа к данным 1С использует свой собственный движок. Однако этот вариант работает только для небольших баз данных и небольшого количества пользователей.

В серверном варианте базу данных 1С необходимо положить в СУБД. Клиент 1С (программа с которой работает пользователь) не соединяется напрямую к СУБД. Для трансляции запросов используется специальная программа сервер 1С (сервер приложений 1С).

Для запроса данных из SQL 1С используются запросы на языке 1С. Они могут быть использованы явно (программист написал в коде программы на языке 1С) или неявно (программист вызывает функцию платформы, которая генерит запрос или такая функция вызывается сама – в форме списка справочника/документа, например).

Сервер 1С транслирует запрос в язык SQL (соответствующую модификацию, поддерживаемую конкретным СУБД) и передает на выполнение в СУБД (SQL 1С).

Кратко о лицензировании различных СУБД

Краткая информация если Вам захочется посмотреть стоимость и в прайс-листах встретятся незнакомые слова:

• Существуют лицензии различных SQL специально для 1С (т.е. «для использования с 1С»)
• Лицензии runtime – купленный SQL можно использовать только с 1С (дешевле)
• Лицензии full-use – купленный SQL можно использовать с разными программами (дороже)
• Существуют лицензии «по количеству процессов сервера» (без ограничения количество работающих пользователей) — PVU
• Существуют комплект лицензий «по сокетам/по клиентам» — LUS
  o Одна лицензия на работу SQL на сервере
  o Лицензии по количеству сокетов/клиентов (т.е. на 5 соединений, на 10 соединений и т.п.).

Здесь и ниже указана очень только обзорная информация по лицензированию, так как лицензирование у всех СУБД очень сложное, есть разные ситуации, скидки, наличие/отсутствие подписки на ИТС, ограничения и правила «по умолчанию»..

Дополнительно необходимо упомянуть, что СУБД может иметь требования к операционной системе (чтобы она была тоже серверная, например, Windows Server). В варианте MS SQL так и есть, но есть и вариант «обхода» — SQL Developer Edition.

Какие SQL можно использовать с 1С

С 1С можно использовать следующие СУБД:

• Microsoft SQL
  Исторически используется чаще всего. Поэтому платформа 1С работает с MS SQL полнофункционально – все типовые конфигурации разработаны именно с прикидкой на нее.
• IBM DB2
  Включена в поддержку недавно. Имеет особенности.
• Oracle
  Включена в поддержку недавно. Имеет особенности.
• PostgreSQL
  Включена в поддержку недавно. Имеет особенности. Полностью бесплатна (OpenSource), поэтому используется чаще остальных. Также используется в случае установки всего комплекса 1С под Linux.

Рассмотрим особенности использования разных СУБД по очереди.

Начнем с MS SQL >>

Проголосовать за этот пост:

1С СЕРВЕР 24/7

Работа в клиент-серверном режиме — не прихоть, а необходимость. В связи с ростом нагрузки на базу данных, ростом одновременно работающих пользователей и физического объема базы 1С переводят в клиент-серверный режим работы. Многие сразу запскают именно этот режим работы оценивая предстоящую нагрузку.
Сразу оговоримся, что для работы программы 1С не является стандартом или требованием работать только в клиент-серверном режиме. Файловая база данных вполне может работать всю жизнь только как файловая и успешно выполнять все задачи. Обычно компании задумываются о клиент-серверном варианте при количестве пользователей 1С более 10 человек.

Основным критерием выбора клиент-серверного варианта являются:

— распределение нагрузки
— разделение зон ответственности по оборудованию (клиент, сервер 1С, сервер СУБД)
— ограничение доступности пользователей к физическому расположению базы данных
— более совершенное администрирование
— использование дополнительных средств SQL

Для того чтобы оперировать терминами клиент-серверного режима работы предлагаем с ними ознакомится. Кто знаком с терминологией может пропустить этот абзац.

Важные термины

Клиент 1С — Запущенный экземпляр программы 1С Предприятие, в котором пользователи выполняют свои обычные функции. Клиенты 1С бывают: Толстый, Тонкий, Web-клиент, мобильный клиент.

СУБД — система управления базами данных. Т.е. — это та программа, которая вносит записи в таблицу базы данных. 1С работает с такими СУБД: Microsoft SQL Server, Postgree SQL, IBM DB2, Oracle Database. В 80% используют Microsoft SQL Server по причине опыта работы ИТ-персонала с продуктами Microsoft и хорошей совместимости 1С с решениями Microsoft.
Microsoft SQL Managemant Studio — программное решение, предназначенное для управления базами данных Microsoft SQL Server.

Сервер 1С — программное решение, обеспечивающее связь Клиенского приложения 1С Предприятие и СУБД. Сервер 1С ведет подсчет лицензий, содержит список подключений, список информационных баз и другие параметры. Со всеми элементами можно ознакомится раскрыв дерево Сервера 1С после инсталляции.

Консоль Сервера 1С — оболочка программного решения Сервер 1С, с помощью которой можно производить настройки Сервера 1С, управлять базами данных 1С, удалять соединения активных пользователей и проводить другие операции.

Кластер в консоли Сервера 1С — структурная единица консоли Сервера 1С, отвечающая за то, на каком порте будет работать Сервер 1С. Кластеров может быть больше одного.

Рабочий сервер в консоили кластера сервера 1С — структурная единица консоли Сервера 1С, с информацией о компьютере, на котором работает Сервер 1С. Как правило это сам локальный компьютер на котором функционирует приложение Сервер 1С.

Рабочий процесс в консоили кластера сервера 1С — в 1С 8.3 автоматически создаваемый процес, решающий задачи обработки данных пользователей. В зависимости от нагрузки рабочих процессво может быть 2 и более.

Сеансы пользователей в Сервере 1С — соединения пользователей с информационными базами 1С.

Агент сервера 1С (ragent) — служба, отвечающая за работу кластера серверов и функционирвание компьютера в составе кластера. По-умолчанию работает на порте 1540.

Менеджер кластера (rmngr) — служба, отвечающая функционирование всего кластера. По-умолчанию работает на порте 1541.

Рабочий процесс (rphost) — служба, отвечающая за обслуживание клиентских приложений и взаимодействие с сервером баз данных. По-умолчанию работает на порте 1561 или на диапазоне портов: 1560-1591.

ЗАПУСК КЛИЕНТ-СЕРВЕРНОЙ 1С

Для перехода на клиент-серверую модель базы данных 1С вам потребуется:
1. Установочный файл сервера 1С Предприятия.
2. Установочный файл клиента 1С Предприятия при условии что он еще не инсталлирован и раньше вы вообще не работали в 1С. Релиз платформы Сервера 1С и клиента 1С Предприятия должны быть одинаковые, например: 8.3.15.1747.
3. Ключ защиты для Сервера 1С и клиентские ключи защиты для 1С Предприятия. Подсчет используемых ключей ведется сервером 1С по принципу одно соединение с базой = один ключ.
4. Установочный файл СУБД. Например, MS SQL Server 2012. Рекомендуемые версии MS SQL — Standart или Enterprise. Версия Standart имеет ограничение на использование ОЗУ — 64 Гб. Версия Enterprise не имеет ограничений.
5. Процессорная или другая лицензия на сервер MS SQL Server.
6. Компьютер (сервер) с достаточным количеством ресурсов для обслуживания подключений к базе данных 1С. Примерный объем ОЗУ можно расчитать исходя из рекомендаций компании 1С: Объем ОЗУ = не менее 70 % физического объема всех баз данных обслуживаемых сервером. Подсчет примерный. Понятно что в базе данных размером 10 Гб может находится 100 и более пользователей. В этом случае сервер с 16 Гб ОЗУ точно не подойдет. Важной особенностью производительности жележа является тактовая частота процессовра. Даже важнее чем количество ядер. Есть мнение, что 1С при обработке данных использует одно ядро процессора, поэтому очень важно не количество ядер, а их качество (тактовая частота, кэш). Подробнее о железе для 1С можно почитать по ссылке.
Будем считать что у вас есть все необходимые инсталлы, ключи, лицензии. Приступаем к установке.

УСТАНОВКА СУБД MS SQL SERVER

Для установки мы выбрали версию MS SQL Server 2008 R2. Установку производим по стандартной схеме под пользователем с полными правами. Соглашаемся со всеми параметрами. В результате у вас должен установится MS SQL Server и Managemant Studio. Пользователь баз данных MS SQL Server по умолчанию — sa. Этот же пользователь и его пароль нужен будет вам всегда при добавлении новых баз данных 1С.

УСТАНОВКА СЕРВЕРА 1С

Установка серверноого приложения 1С почти такое же как установка обычной платформы 1С Предприятие, за исключением того, что в ходе установки нужно создать пользователя кластера сервера 1С — USR1CV8. Установщик сам предлагает создать пользователя в ходе установки. В ходе установки нужно установить компонету «Администрирование сервера 1С: Предприятие». Это есть консаль сервера, в которую нужно зайти после завершения установки и произвести настройки.

НАСТРОЙКА СЕРВЕРА 1С

В консоли кластера Сервера 1С у вас автоматически должны появится следующие разделы:

— центральный сервер
— кластер

Информационную базу необходимо добавлять вручную. Для того чтобы добавить информационную базу в клиент-серверном режиме вам потребются такие параметры:

— Кластер серверов 1С Предприятие. Локальное имя компьютера, в случае если база создается на том же сервере, где установлен кластер 1С: localhost или 127.0.0.1 Либо, если база добавляется не на компьютере, где установлен кластер, тонужно прописать имя сервера в сети, например: 1csrv.
— Имя информационной базы в кластере. Произвольное название из латинских букв, цифр, спецсимволов.
— Тип СУБД. Необходимо выбрать из предлагаемого списка тип СУБД, на которой будет работать база.
— Сервер база данных. Если сервер СУБД и 1С Сервер расположены на одном ПК, то прописывается то же имя что и пункте №1 — кластер серверов 1С Предприятие. В случае если СУБД и Сервер 1С (кластер) рабо
— Имя базы данных. Можно указать то же имя что и Имя информационной базы в кластере в пункте 3. Либо внести другое произвольное из латинских букв, цифр, спецсимволов.
— Пользователь базы данных. Пользователь MS SQL Server — sa.
— Пароль пользователя. Пароль пользователя sa, который был установлен при инсталляции MS SQL Server.

Если информационной базы нет в MS SQL Server, ставите галочку «Создать базу данных в случае ее отсутствия».

Если все сделали правильно, то создастся новая база данных. После этого можно заходить в Конфигуратор и загружать информационную базу *.dt
Обычные пользователи не увидят разницу между работой файловой и серверной версии 1С. Для них вообще нет никакой разницы. Чтобы узнать в каком режиме сейчас работает база данных 1С необходимо в 1С зайти в меню Справка — О программе — строчка Режим (файловый/серерный).

Работа с базами данных PostgreSQL

1. Создание подключения 2. Выборка данных из базы на языке SQL 3. Создание, добавление, изменение и удаление записей SQL PostgreSQL
Наиболее часто встречающаяся на практике систем СУБД для 1С – это, конечно же, MSSQL. А вот номером два является база PostgreSQL. В данной статье о ней и поговорим. База данных PostgreSQL – это система СУБД с открытым исходным кодом.
Но не только для 1С используется Postgre. Это полноценная СУБД, которую широко применяют для решения различных задач. А это значит, что с большой долей вероятности нужно будет вести обмен с 1С при помощи прямых запросов. Давайте рассмотрим, как работать с PostgreSQL из 1С.

Для начала необходимо будет скачать драйвер необходимой разрядности с официального сайта. После его установки переходим в конфигуратор 1С.

1. Создание подключения.

В строке соединения необходимо указать имя драйвера, сервер, порт (по необходимости), имя базы данных, логин, пароль и кодировку (по необходимости).
Пример кода:

Так же создадим необходимые для дальнейшей работы объекты и установим активное соединение. Эти процедуры выполняем единожды, после создания подключения:

После окончания работы с соединением обязательно закрывайте его:

Сами запросы формируются на языке SQL. Он напоминает язык 1С, но имеет англоязычный синтаксис, поэтому советую изучить дополнительную информацию по составлению прямых запросов SQL.

2. Выборка данных из базы на языке SQL.

Для выборки мы создаем объект «Команда», в которую и будет передан составленный текст прямого запроса. После чего мы выполняем команду «Execute()», получив таким образом выборку данных. Выбираем первую запись «MoveFirst()» (аналог команды 1С РезультатЗапроса.Выбрать()), и в цикле получаем следующие записи «MoveNext()» (по аналогии с командой языка 1С Выборка.Следующий()). Пример кода:

3. Создание, добавление, изменение и удаление записей PostgreSQL.

Для добавления/создания записей используется соединение, и команда «Execute», в которую передается текст запроса.
Пример добавления:

Для изменения данных используется такая же конструкция, как и при создании/добавлении, за исключением самого текста запроса в базы данных на языке SQL. Здесь используется оператор UPDATE, где нужно указать, что мы меняем: SET – на какие значения, и WHERE – условие замены/обновления (обычно здесь задается конкретный уникальный идентификатор, если требуется изменить только одну запись).
Пример:

Для удаления используется оператор DELETE. Пример построения запроса очень схож с изменением записей:

В итоге мы видим, что работать с базой данных SQL из 1С достаточно просто, ну, по крайней мере, не сложнее чем с другими популярными системами СУБД.
Специалист компании «Кодерлайн» Вадим Хоменко

Вас могут заинтересовать следующие статьи:

94 [PROP_CODE] => TAGS2 [TITLE] => Вас могут заинтересовать следующие семинары: ) —> 95 [PROP_CODE] => TAGS [TITLE] => Вас могут заинтересовать следующие вебинары: ) —> Обновления [1] => Как сделать в 1С [2] => Конвертация данных [3] => Обмен между базами [4] => Оценка задач [5] => Отчеты в 1С [6] => 1С: Конвертация данных [7] => Закрытие месяца [8] => 1С: Управление торговлей [9] => БУ [10] => com-объекты [11] => Перенос данных [12] => РСБУ [13] => 1С: Сценарное тестирование [14] => Правила обмена [15] => Запросы 1С [16] => LINUX [17] => 1С:Управление производственным предприятием [18] => Моделирование [19] => Отчетность [20] => 1С:Комплексная автоматизация [21] => Производство [22] => HTTP [23] => Управление проектами [24] => Отпуск [25] => MS SQL Server [26] => Расширение конфигурации [27] => XML [28] => 1С: WMS Управление складом [29] => Торговое оборудование [30] => 1С:Управление нашей фирмой [31] => Администрирование 1С [32] => 1С: Платформа [33] => WEB [34] => Лицензии 1С [35] => Оптимизация [36] => 1С:Зарплата и Управление Персоналом [37] => 1С: Документооборот [38] => Excel [39] => 1С: ERP [40] => ADO [41] => Внедрение [42] => Продажи [43] => 1С: Розница [44] => 1С: CRM [45] => 1С:Бухгалтерия [46] => Интеграция 1С [47] => Налоги [48] => Полезные обработки [49] => МСФО [50] => СКД [51] => Word [52] => WEB-сервисы 1С [53] => Внедрение ERP [54] => Сравнение конфигураций [55] => Проводки 1С [56] => Корпоративное сопровождение [57] => Лизинг [58] => 1С: Колледж ) —>