Потому что в лицензионной политике 1С прямо запрещено лезть в таблицы в базе данных. Вся работа только средствами платформы.
В 90% случаев нет необходимости дополнительно гадать, что за объект, т.к. он известен из контекста анализируемого запроса. Запрос ВСЕГДА известен, он всегда написан на языке 1С и читаем. Плюс есть его трансляция на скуль и есть план выполнения запроса. Поэтому из контекста и известно всё.
Инфорег - регистр сведений. Какой конкретно - понятно из контекста анализируемого запроса, написанного на языке 1С. В некоторых случаях требуется посмотреть что это за конкретный объект метаданных, но не очень часто.
Я, как бы, понимаю, вы тут представитель упомянутого решения, усиленно топите за свой продукт. И пытаетесь выйти на рынок РФ, но не очень-то удается...
. Также автоматически генерируются запросы на основе логики, написанной на внутреннем языке. Основная разница в том, что в 1С как раз есть "псевдо-SQL", который транслируется в SQL очень близко, а в lsFusion все запросы генерируются автоматически.
Вот именно в этом и ключевая разница в подходе, зачем нужно понимание плана запроса у вас и почему его не требуется в 1С в обычном режиме работы. В общем случае ваш разработчик не знает, какой запрос будет сформирован. В 1С есть понимание, какой запрос будет исполняться, более того, есть достаточно широкий опыт и рекомендации сообщества и вендора как строить эффективные запросы. Опять же, сама платформа 1С позволяет конкретизировать и запрос на языке и запрос на sql и получить план выполнения конкретного запроса. Нативно, без использования даже средств sql.
А если у вас запрос на 4МБ ? Да и у автора на скрине как раз и есть лог длинных запросов. Как там сходу определить для чего эти запросы, и где они вообще вызываются, если все имена там Fld2983482 ?
Пример автора - это узкий круг запросов, возникающий в определённые моменты развития системы, когда размер базы достигает уже сотни гигабайт. Приведённый пример автором - это решение вендора из коробки, причём встречающийся в крайне редких случаях, и там да, бывают косяки производительности. Понимание где вызываются - есть и прямое, вплоть до точки в коде. В редких случаях, когда такие запросы вызываются неявно, платформа позволяет это отследить и найти конкретную строку. Опять же, сам текст запроса прозрачен и читается разработчиком, т.к. он ТРАНСЛИРУЕТСЯ а не ГЕНЕРИРУЕТСЯ.
Кроме того, вот допустим у вас сформировался запрос с неправильным планом ? Вот что Вы планируете делать в таком случае ? Единственный вариант, как и в lsFusion - это найти конкретное место и что-то поменять. В lsFusion для этого хотя бы есть механизм, который позволяет менять физическую структуру хранения, вообще без изменения логики. Но иногда приходится и логику менять. И все это требует понимания, где именно ошибся планировщик запроса.
Когда запрос сформировался с неправильным планом - это всегда известная точка. Платформа содержит встроенные средства замера производительности. Мы точно знаем какая строка кода, какой вызванный запрос работает медленно. Мы всегда знаем, как платформа построила таблицы данных, где какие индексы используются, более того, в большинстве случаем можем явно влиять на создание дополнительных индексов. Мы всегда можем оптимизировать сам запрос, т.к. он прописан явно и продвинутый программист всегда знает, какие места могут вызвать тормоза при выполнении.
----
В отношении же самой статьи - рекламная статья решения, которое неявно нарушает лицензионную политику 1С. Автор сознательно не показывает место и текст запроса на языке 1С, который приводит к генерации такого огромного запроса. Так же не слова не сказано о размере базы, и прочих параметрах, необходимых для понимания когда такие запросы генерируются.
Просто потому что "Захотелось", либо слегка поменялась логика обработки конкретных данных. И для удобства чтения и обработки данных меняется наименование поля.
В этом случае нет смысла трогать таблицу от слова совсем.
Потому что нет прямой необходимости анализировать планы запросов. Это тонкий тюнинг конкретного запроса, в котором понятно, какие объекты запрашиваются.
Насколько вижу, lsFusion, это браузерное решение на js, что влечет за собой прямую работу с SQL, поэтому разработчикам и необходимо смотреть как реагирует SQL на их действия.
За взаимодействие с сервером БД отвечает сервер приложения 1С.
А решение оптимизатора, описанное тут - неявно нарушает лицензионную политику 1С.
Тем более непонятна необходимость таких анализов в 1С:Бухгалтерии.
Кроме того, большая часть современных отчетов построена на СКД. Куда таким методом загружать данные неудобно и не эффективно. Есть более простые и удобные, как для пользователя, так и для программиста методы.
Вообще, следуя букве закона и мнению ВС РФ, каждая цель сбора данных должна быть оформлена отдельным согласием.
И право передачи третьим лицам, так же, должно быть отдельно.
Ну и никто не запрещает, для согласий в бумажном виде, сразу прикладывать отзыв от согласия на все операции, кроме необходимых для конкретного договора.
А больше нет настолько массовых ОДИНАКОВЫХ решений. А тут процент багов именно таких - большой именно за счет массовости. Плюс специфика работы с данными и большого количества человеческого фактора при вводе данных.
Судя по описанию, у вас триггеры привязываются к таблицам. Таблицы 1С, в некоторых случаях реструктуризации, создает новые и копирует в них данных из старых, т.е. триггер уже не будет работать.
Кроме того, что это грубейшее нарушение, так ещё и сложности с настройкой и поддержанием такого механизма при изменении структуры БД и структуры конкретного объекта в 1С, ибо платформа пересоздает таблицы и придётся перенастраивать триггеры и индексы после каждого изменения.
Можно использовать гит. Функционал есть. Но, в большинстве случаев разработка ведется в проприетарной системе совместной разработки. И в среде 1С не принято цеплять прод к системе разработки. Обычно это самостоятельная база, все релизы на которые накатывается осознанно из специально подготовленного файла.
Платформа 1С вполне адекватно умеет менять структуру данных. Да, требуется отправить прод на техническое обслуживание, но сама бизнес-направленность подразумевает, что такие приостановки допустимы в моменты низкой активности, в основном - ночью.
Развернуть копию - это, буквально, поднять текущий бэкап SQL базы прода в отдельную базу и прописать путь к ней. Всё, будет полноценный инстанс, в котором делай что хочешь. Что касается тестов - тесты есть. В силу специфики, запускаются вручную.
В 1С ООП реализовано. Да не полностью, нет, непонятно зачем нужных в бизнес-логике наследований, полиморфизмов и прочих механизмов реализации БИБЛИОТЕК кода, пригодных для переиспользования в других проектах. Платформа предоставляет специализированные объекты, предоставляет возможность на основании этих объектов создать прикладные объекты (вот оно ваше наследование). Имеет типизацию. Имеет возможность создавать методы для объектов. Что ещё от ООП нужно для создания прикладной бизнес-логики?
Стоит указать желаемые позиции. и указать что позиция тимлида не рассматривается. И на вопросы рекрутеров честно отвечать почему. Работодатель адекватно относится к тем кандидатам, которые говорят - попробовал, не моё потому что, далее список причин. Вполне нормально будет сказать - хочу кодить, а на позиции тимлида этого почти нет, поэтому возвращаюсь обратно.
Не вижу аргументов в ссылке. Ещё раз - там говориться только про скорость обработки и когнитивной реакции в определённых ситуациях. Никак не про скорость обработки информации мозгом в целом. Вы это измерить не в состоянии на текущем уровне развития науки в области мозговой деятельности.
Т.е. статью буквально воспринимать стоит как: Тестовый человек при подаче ему информации со скоростью 60 кбит/с способен её осознать и среагировать, т.е., условно, жмакнуть на кнопку когда в потоке идёт такая задача. Опять же, в зависимости от языка 60 кбит/с - совершенно разный объём информации... Так что ваши аргументы ничтожны в контексте технологий передачи двоичных данных посредством мобильной сети.
Так и у вас аргументов нет, кроме статейки в интернете. Пробежался наискосок по статье. Ваши выводы статья не подтверждает. Там исключительно - скорость обработки и когнитивной реакции в определённых условиях, не более того.
Будьте добры, оцифруйте 2к поток стрима с ютуба в кбит/с обработки и когнитивной реакции мозга.
И что это покажет в контексте оценки опытности сотрудника в написании сложных правил переноса данных из одной системы в другую?
В области учетных систем ВСЕГДА кандидат рассматривается в контексте задач, которые он будет решать после приема на работу. И если требуется выдать тестовое задание - то это задание будет именно в той узкой области, знания и опыт в которой, критичны для текущей вакансии.
Тот кто работает с 1С больше 1-2 лет, способны накидать указанный детский зоопарк за 1 день, поэтому такая задача не будет являться показателем.
Каким образом система кормления зверей покажет, как сотрудник справляется с задачей синхронизации данных между типовыми решениями со сложными правилами конвертации данных из одной системы в другую? При этом именно такой опыт является критичным при рассмотрении кандидата?
Ну и да, такая система - либо это уровень стажёр, делается за несколько часов, либо это уровень сеньор с опытом архитектора и проектом на несколько месяцев.
Не нужно судить по опыту вэб и мобильной разработки об особенностях задач учетных систем.
Зачем платформе переименовывать поле в таблице, если ничего не меняется с точки зрения структуры?
Анализ запросов с анализом плана запросов - не ежедневная работа и до этого доходят только на крупных базах и точечно.
Прямые запросы к БД напрямую запрещены лицензионной политикой 1С.
Потому что в лицензионной политике 1С прямо запрещено лезть в таблицы в базе данных. Вся работа только средствами платформы.
В 90% случаев нет необходимости дополнительно гадать, что за объект, т.к. он известен из контекста анализируемого запроса. Запрос ВСЕГДА известен, он всегда написан на языке 1С и читаем. Плюс есть его трансляция на скуль и есть план выполнения запроса. Поэтому из контекста и известно всё.
Инфорег - регистр сведений. Какой конкретно - понятно из контекста анализируемого запроса, написанного на языке 1С. В некоторых случаях требуется посмотреть что это за конкретный объект метаданных, но не очень часто.
Я, как бы, понимаю, вы тут представитель упомянутого решения, усиленно топите за свой продукт. И пытаетесь выйти на рынок РФ, но не очень-то удается...
Вот именно в этом и ключевая разница в подходе, зачем нужно понимание плана запроса у вас и почему его не требуется в 1С в обычном режиме работы. В общем случае ваш разработчик не знает, какой запрос будет сформирован. В 1С есть понимание, какой запрос будет исполняться, более того, есть достаточно широкий опыт и рекомендации сообщества и вендора как строить эффективные запросы. Опять же, сама платформа 1С позволяет конкретизировать и запрос на языке и запрос на sql и получить план выполнения конкретного запроса. Нативно, без использования даже средств sql.
Пример автора - это узкий круг запросов, возникающий в определённые моменты развития системы, когда размер базы достигает уже сотни гигабайт. Приведённый пример автором - это решение вендора из коробки, причём встречающийся в крайне редких случаях, и там да, бывают косяки производительности. Понимание где вызываются - есть и прямое, вплоть до точки в коде. В редких случаях, когда такие запросы вызываются неявно, платформа позволяет это отследить и найти конкретную строку. Опять же, сам текст запроса прозрачен и читается разработчиком, т.к. он ТРАНСЛИРУЕТСЯ а не ГЕНЕРИРУЕТСЯ.
Когда запрос сформировался с неправильным планом - это всегда известная точка. Платформа содержит встроенные средства замера производительности. Мы точно знаем какая строка кода, какой вызванный запрос работает медленно. Мы всегда знаем, как платформа построила таблицы данных, где какие индексы используются, более того, в большинстве случаем можем явно влиять на создание дополнительных индексов. Мы всегда можем оптимизировать сам запрос, т.к. он прописан явно и продвинутый программист всегда знает, какие места могут вызвать тормоза при выполнении.
----
В отношении же самой статьи - рекламная статья решения, которое неявно нарушает лицензионную политику 1С. Автор сознательно не показывает место и текст запроса на языке 1С, который приводит к генерации такого огромного запроса. Так же не слова не сказано о размере базы, и прочих параметрах, необходимых для понимания когда такие запросы генерируются.
Просто потому что "Захотелось", либо слегка поменялась логика обработки конкретных данных. И для удобства чтения и обработки данных меняется наименование поля.
В этом случае нет смысла трогать таблицу от слова совсем.
Потому что нет прямой необходимости анализировать планы запросов. Это тонкий тюнинг конкретного запроса, в котором понятно, какие объекты запрашиваются.
Насколько вижу, lsFusion, это браузерное решение на js, что влечет за собой прямую работу с SQL, поэтому разработчикам и необходимо смотреть как реагирует SQL на их действия.
За взаимодействие с сервером БД отвечает сервер приложения 1С.
А решение оптимизатора, описанное тут - неявно нарушает лицензионную политику 1С.
Наличие таких отборов - признак хаоса в учете.
Тем более непонятна необходимость таких анализов в 1С:Бухгалтерии.
Кроме того, большая часть современных отчетов построена на СКД. Куда таким методом загружать данные неудобно и не эффективно. Есть более простые и удобные, как для пользователя, так и для программиста методы.
Архитектор 1С не занимается расследованием. Он занимается проектированием инфраструктуры под потребности внедрения и разработки системы как набора ПО.
Вообще, следуя букве закона и мнению ВС РФ, каждая цель сбора данных должна быть оформлена отдельным согласием.
И право передачи третьим лицам, так же, должно быть отдельно.
Ну и никто не запрещает, для согласий в бумажном виде, сразу прикладывать отзыв от согласия на все операции, кроме необходимых для конкретного договора.
А больше нет настолько массовых ОДИНАКОВЫХ решений. А тут процент багов именно таких - большой именно за счет массовости. Плюс специфика работы с данными и большого количества человеческого фактора при вводе данных.
Судя по описанию, у вас триггеры привязываются к таблицам. Таблицы 1С, в некоторых случаях реструктуризации, создает новые и копирует в них данных из старых, т.е. триггер уже не будет работать.
Кроме того, что это грубейшее нарушение, так ещё и сложности с настройкой и поддержанием такого механизма при изменении структуры БД и структуры конкретного объекта в 1С, ибо платформа пересоздает таблицы и придётся перенастраивать триггеры и индексы после каждого изменения.
Можно использовать гит. Функционал есть. Но, в большинстве случаев разработка ведется в проприетарной системе совместной разработки. И в среде 1С не принято цеплять прод к системе разработки. Обычно это самостоятельная база, все релизы на которые накатывается осознанно из специально подготовленного файла.
Платформа 1С вполне адекватно умеет менять структуру данных. Да, требуется отправить прод на техническое обслуживание, но сама бизнес-направленность подразумевает, что такие приостановки допустимы в моменты низкой активности, в основном - ночью.
Развернуть копию - это, буквально, поднять текущий бэкап SQL базы прода в отдельную базу и прописать путь к ней. Всё, будет полноценный инстанс, в котором делай что хочешь. Что касается тестов - тесты есть. В силу специфики, запускаются вручную.
В 1С ООП реализовано. Да не полностью, нет, непонятно зачем нужных в бизнес-логике наследований, полиморфизмов и прочих механизмов реализации БИБЛИОТЕК кода, пригодных для переиспользования в других проектах. Платформа предоставляет специализированные объекты, предоставляет возможность на основании этих объектов создать прикладные объекты (вот оно ваше наследование). Имеет типизацию. Имеет возможность создавать методы для объектов. Что ещё от ООП нужно для создания прикладной бизнес-логики?
Чатик уже есть. Видеозвонки есть. Сторисы, если будет потребность, запилят и будут продавать за бабло.
Стоит указать желаемые позиции. и указать что позиция тимлида не рассматривается. И на вопросы рекрутеров честно отвечать почему.
Работодатель адекватно относится к тем кандидатам, которые говорят - попробовал, не моё потому что, далее список причин. Вполне нормально будет сказать - хочу кодить, а на позиции тимлида этого почти нет, поэтому возвращаюсь обратно.
Не вижу аргументов в ссылке. Ещё раз - там говориться только про скорость обработки и когнитивной реакции в определённых ситуациях. Никак не про скорость обработки информации мозгом в целом. Вы это измерить не в состоянии на текущем уровне развития науки в области мозговой деятельности.
Т.е. статью буквально воспринимать стоит как: Тестовый человек при подаче ему информации со скоростью 60 кбит/с способен её осознать и среагировать, т.е., условно, жмакнуть на кнопку когда в потоке идёт такая задача. Опять же, в зависимости от языка 60 кбит/с - совершенно разный объём информации... Так что ваши аргументы ничтожны в контексте технологий передачи двоичных данных посредством мобильной сети.
В сферическом вакууме? Найдите соту 4Г, не тестовую, которая ОДНОМУ абоненту, низкомобильному, в условиях развитого мегаполиса отдаст 1Гбит/с трафика.
Так и у вас аргументов нет, кроме статейки в интернете. Пробежался наискосок по статье. Ваши выводы статья не подтверждает. Там исключительно - скорость обработки и когнитивной реакции в определённых условиях, не более того.
Будьте добры, оцифруйте 2к поток стрима с ютуба в кбит/с обработки и когнитивной реакции мозга.
И что это покажет в контексте оценки опытности сотрудника в написании сложных правил переноса данных из одной системы в другую?
В области учетных систем ВСЕГДА кандидат рассматривается в контексте задач, которые он будет решать после приема на работу. И если требуется выдать тестовое задание - то это задание будет именно в той узкой области, знания и опыт в которой, критичны для текущей вакансии.
Тот кто работает с 1С больше 1-2 лет, способны накидать указанный детский зоопарк за 1 день, поэтому такая задача не будет являться показателем.
Каким образом система кормления зверей покажет, как сотрудник справляется с задачей синхронизации данных между типовыми решениями со сложными правилами конвертации данных из одной системы в другую? При этом именно такой опыт является критичным при рассмотрении кандидата?
Ну и да, такая система - либо это уровень стажёр, делается за несколько часов, либо это уровень сеньор с опытом архитектора и проектом на несколько месяцев.
Не нужно судить по опыту вэб и мобильной разработки об особенностях задач учетных систем.