С какими СУБД работал?

СУБД в профессиональной практике

Основные СУБД

В своей практике как 1С разработчик работал с тремя основными СУБД, которые поддерживает платформа 1С.

1. MS SQL Server

Это была первая и основная СУБД в моей карьере. Использовалась в большинстве проектов на 1С в крупных компаниях:

Версии: SQL Server 2012, 2016, 2019

Где использовал:

• Разработка конфигураций ЗУП, УТ на базе SQL Server
• Оптимизация запросов и индексов
• Миграция данных между базами
• Создание резервных копий и восстановление
• Работа с План выполнения (Query Execution Plan) для анализа медленных запросов

Опыт:

• Понимаю как индексы влияют на производительность
• Работал с фрагментацией индексов и их перестройкой
• Писал прямые SQL запросы для интеграций
• Использовал SQL Server Management Studio для администрирования
• Знаю базовый SQL (SELECT, JOIN, WHERE, GROUP BY, оконные функции)

Пример запроса для анализа:

-- Анализ медленных запросов
SELECT 
    t1.Сумма,
    COUNT(t2.КолвоСтрок) as СтрокВДокументе
FROM РеализацияТовара t1
LEFT JOIN ТабличнаяЧастьПозиции t2 
    ON t1.КодДокумента = t2.КодДокумента
WHERE t1.Дата > DATEADD(MONTH, -1, GETDATE())
GROUP BY t1.Сумма
ORDER BY Сумма DESC

2. PostgreSQL

Вторая СУБД, с которой работал в проектах open-source и некоторых cloud решениях:

Версии: PostgreSQL 9.6, 11, 12, 13

Где использовал:

• Разработка на 1С с PostgreSQL бекенд
• Настройка параллельных сеансов 1С
• Резервное копирование через pg_dump
• Мониторинг через pgAdmin

Отличия от SQL Server:

• Команды отличаются (TIMESTAMP vs DATETIME, SERIAL vs IDENTITY)
• Отсутствие трансформации UTF-16 — PostgreSQL работает с UTF-8
• Case sensitivity в SELECT, TABLE, COLUMN наоборот (чувствителен к регистру)
• Встроенная репликация проще на PostgreSQL

Опыт:

• Работал с индексами через EXPLAIN ANALYZE
• Настраивал параметры производительности (shared_buffers, work_mem)
• Использовал pg_stat_statements для анализа медленных запросов

3. Встроенная СУБД 1С

Маленькие проекты, внутренние приложения, тестовые среды:

Версии: СУБД файловая (*.1cd формат) и серверная встроенная

Где использовал:

• Разработка standalone приложений (когда нет дома информационная база)
• Тестирование конфигураций перед развёртыванием на SQL Server
• Демонстрации клиентам
• Обучение новых разработчиков (быстро развернуть, не нужна СУБД)

Ограничения:

• Только один пользователь может работать (в сетевом режиме нестабильна)
• Плохая производительность при большом объёме данных
• Без инструментов мониторинга и анализа
• Не подходит для production

Операции которые выполнял

Создание резервных копий

// На SQL Server: через 1С
Годсервис = Новый COMОбъект("V81.COMConnector");
Сервер = Годсервис.ConnectToInfoBase(
    "Srvr=localhost:1541;Ref=ИБ_Тест;Usr=Администратор;Pwd=");
// ...

Или через SQL Server Management Studio (полная копия базы, логи, и т.д.).

Анализ производительности

SQL Server:

- Включу трассировку в Profiler
- Смотрю Query Execution Plan
- Анализирую scan vs seek операции
- Видны "дорогие" операции

PostgreSQL:

EXPLAIN ANALYZE SELECT ...;
-- Видны: Seq Scan, Index Scan, Hash Join, Sort и их стоимость

Миграция данных

Оч часто нужно перенести базу с одной СУБД на другую (например, с файловой на SQL Server):

// Инструменты 1С
- Выгрузка в XML/JSON из файловой БД
- Загрузка в SQL Server БД
- Или использование инструмента "Consolidation"

Знание SQL

Как 1С разработчик, моё знание SQL — среднее-продвинутое:

Знаю:

• SELECT, INSERT, UPDATE, DELETE
• JOIN (INNER, LEFT, RIGHT, FULL)
• GROUP BY, HAVING, ORDER BY
• Агрегирующие функции (SUM, COUNT, AVG, MAX)
• Подзапросы и CTE (WITH clause)
• Оконные функции (ROW_NUMBER, RANK, LAG, LEAD)
• Индексы и их создание
• Транзакции (BEGIN, COMMIT, ROLLBACK)

Не знаю глубоко:

• Сложные процедуры и триггеры (в 1С редко пишу на SQL)
• Реplication и шардирование
• Оптимизация на уровне СУБД (для этого есть DBA)

Знание администрирования

Базовое:

• Создание базы данных и подключение 1С
• Резервное копирование
• Восстановление из backup
• Управление пользователями и правами доступа
• Мониторинг дискового пространства

Не администратор, но знаю:

• Когда нужно обратиться к DBA
• Как диагностировать проблемы (медленные запросы, нехватка памяти)
• Где смотреть логи СУБД

Выводы

Мой уровень владения СУБД — разработчик, а не администратор:

• Пишу запросы и понимаю как они выполняются
• Могу оптимизировать запросы через индексы и переписывание
• Понимаю основные операции администрирования
• Знаю когда вызывать DBA для глубокого анализа и настройки

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