Pull to refresh

Comments 8

Кстати язык запросов 1С очень похож на SQL

Я бы так не сказал. Там реализован только один оператор - SELECT. Скорее, это диалект одного оператора языка SQL с добавлением специализированных виртуальных таблиц и других полезных для этой области применения штучек.

Привет! Вы правы, что язык запросов 1С имеет свои особенности и отличия от стандартного SQL. Однако есть и схожие моменты, о которых стоит упомянуть.

Действительно, в языке запросов 1С основное внимание уделено оператору выбора данных (SELECT), и многие привычные для SQL операторы, такие как INSERT и DELETE, отсутствуют в привычном формате. Это связано с тем, что в 1С управление данными осуществляется через объекты системы (ORM), а не через прямые запросы к базе данных.

Тем не менее, оба языка поддерживают следующие общие возможности:

  • Соединения таблиц (JOIN): можно объединять данные из нескольких таблиц.

  • Условия фильтрации (WHERE): позволяют задавать критерии отбора данных.

  • Алиасы: используются для упрощения ссылок на таблицы и столбцы.

  • Временные таблицы: используются для хранения промежуточных результатов запросов.

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

Спасибо за ваш интерес и внимание к деталям!

Если уж совсем правду рассказать, то там и Insert есть - вставка во временные таблицы (таким образом оно превращается в create temporary table + insert into temporary from ...), которые сейчас почти в каждом запросе 1С-ники используют. Жаль, что нет общих табличных выражений, которые могли бы заменить львиную долю временных таблиц.

Кстати, да. Справедливое замечание)
Но не полновесный insert, а только выборка в таблицу...

В сфере 1С огромная проблема - отсутствие глоссария и единой терминологии на уровне вендора и сообщества.

Разные компании вкладывают совершенно разный смысл в термины "консультант", "бизнес-аналитик", "системный аналитик". Либо наоборот, называет ту же роль всеми этими терминами.

Отчасти это идет из истории развития отрасли: эволюция от "девочки из 1с, которая приезжает раз в месяц и помогает главбуху закрывать период" до "команда внедрения в составе аналитиков, разработчиков, функциональных и технических архитекторов" прошла лет за 20, и далеко не во всех франчах этот процесс завершился.

Даже у вас в статье описан некий "котопес", который должен разбираться и в бизнесе лучше сотрудников заказчика (роль бизнес-аналитика) и в системе достаточно для перевода бизнес-требований от БА на язык объектов и функций системы и подготовки ТЗ (роль системного аналитика).

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

Вы абсолютно правы, что в сфере 1С действительно существует проблема с отсутствием глоссария и единой терминологии, и что роль аналитика зачастую очень размыта.

Что касается «котопса». Мы хотели донести, что существует два подхода: внедрение типовой коробки и собственная разработка. В первом случае аналитик 1С больше похож на бизнес‑аналитика‑консультанта, которому важно знание отраслевой конфигурации, а не глубокое понимание объектов платформы 1С. Во втором же случае ключевыми являются знания платформы и ее объектов, работа с требованиями на разработку.

Сейчас мы активно развиваем внутренний центр экспертизы системного анализа, одной из целей которого является определение границ роли системного аналитика с точными критериями DOR (Definition of Ready) и DOD (Definition of Done).

Это действительно актуальная тема, границы бизнес/системного анализа зачастую бывают очень размытыми и это касается не только 1С. Этот вопрос заслуживает отдельной статьи.

Написание задачи разработчику (включая описание API).

Можно понять, описание функциональных требований к API, но описание API - это уже задача разработчика, а не аналитика.

Иначе получится юрист-штукатур.

Интересная статья. Тоже хотелось бы в будущем дорасти до системного аналитика

Sign up to leave a comment.