Варианты логирования кода 🔂
Довольно частая задача для программиста - это сохранить какой-то промежуточный результат выполнения кода.
Бывает это требуется сделать, когда нет возможности подключить отладку, либо сохранить тело запроса обмена данными.
Для решения данных задач есть множество вариантов, сегодня расскажу о наиболее частых.
⏩ 1. Запись в журнале регистрации.
Это нормальный вариант, если это очень редко требуется, когда, например, критичная ошибка. Но для постоянной записи, данный вариант использовать нехорошо, так как может разрастаться и захламляться журнал регистрации.
⏩ 2. Запись в регистр сведений.
Отличный вариант, если требуется делать постоянные записи, например по http запросам в сторонние API. Но требует добавление нового регистра сведений в конфигурацию. Выходом может стать расширение, если у основной конфигурации установлен нужный режим совместимости.
⏩ 3. Запись в файл.
Подойдёт, если нам нужно постоянно сохранять какие-то примитивные данные, делать это независимо от транзакции или нет возможности добавить регистр сведений. Для этого задаётся каталог, куда пишутся файлы именем текущей даты и далее можно уже считывать эти данные вручную, давать пользователям, либо обрабатывать другими программами.
⏩ 4. Передача данных в другую базу.
Например, по http сервису, и уже в той базе хранить нужную информацию.
У этого варианта есть как плюсы, так и минусы. К минусам можно отнести необходимость поддержки дополнительной базы и обмена между ними. А к плюсам я бы отнес то, что можно настроить хранение в нужном виде, хранить столько сколько нужно информации по объему, и если это не требуется для дальнейшей обработки в основной базе, то и захламляться основная база не будет.
А обсудить наиболее интересный вариант, или тот который используете вы, можно в комментариях💬
> > > Случайный пост < < <
#ЕБ_Повседневность
Довольно частая задача для программиста - это сохранить какой-то промежуточный результат выполнения кода.
Бывает это требуется сделать, когда нет возможности подключить отладку, либо сохранить тело запроса обмена данными.
Для решения данных задач есть множество вариантов, сегодня расскажу о наиболее частых.
Это нормальный вариант, если это очень редко требуется, когда, например, критичная ошибка. Но для постоянной записи, данный вариант использовать нехорошо, так как может разрастаться и захламляться журнал регистрации.
Отличный вариант, если требуется делать постоянные записи, например по http запросам в сторонние API. Но требует добавление нового регистра сведений в конфигурацию. Выходом может стать расширение, если у основной конфигурации установлен нужный режим совместимости.
Подойдёт, если нам нужно постоянно сохранять какие-то примитивные данные, делать это независимо от транзакции или нет возможности добавить регистр сведений. Для этого задаётся каталог, куда пишутся файлы именем текущей даты и далее можно уже считывать эти данные вручную, давать пользователям, либо обрабатывать другими программами.
Например, по http сервису, и уже в той базе хранить нужную информацию.
У этого варианта есть как плюсы, так и минусы. К минусам можно отнести необходимость поддержки дополнительной базы и обмена между ними. А к плюсам я бы отнес то, что можно настроить хранение в нужном виде, хранить столько сколько нужно информации по объему, и если это не требуется для дальнейшей обработки в основной базе, то и захламляться основная база не будет.
А обсудить наиболее интересный вариант, или тот который используете вы, можно в комментариях
> > > Случайный пост < < <
#ЕБ_Повседневность