Нее, для временной отладки может и сойдет. Но на постоянку либо журнал регистрации, либо регистр сведений, либо внешняя база данных. Регистр сведений быстрее очищается, а это важно для логов. Логи за год могут очищатся две недели. Приходилось уже просто очищать запросами напрямую в sql. Ссылку кидать на лог , очень редко когда может пригодиться. Во вторых надо замерить запись документа и запись набора регистра. Мне кажется регистр запишется быстрее. И в РС можно записывать за один раз, накопленные логи. Часто начинаешь анализировать быстродействие, а логи и занимают более 50% времени от всей операции.

Логи лучше писать в справочник. Минимум индексов. Быстрая запись. Ссылка на объект есть. В базе данных одна таблица.

@ArgentumSych

2 жыл бұрын

Да. Только так и делаю. Сразу есть GUID, а скорость та же, что и в регистре.

@priklyuchencher

2 жыл бұрын

Индекс у регистра по умолчанию один. А у справочника по умолчанию 3. Что бы у справочника был один индекс нужно отказаться от стандартных наименования и кода.

@nikolasx2010

2 жыл бұрын

100% Справочник это супер. А ответ просто супер, потому что программист может случайно стереть! Так он и базу удалить может, так давайте на бумаге вести учет!

@dobpilot4

Жыл бұрын

У документа можно создать индекс с доп упорячиванием, что для отборов по полю и дате мы будем попадать на покрывающий запрос. А идея говно, логи надо хранить в специализированных баз данных, отдельно от основной. Мы у себя сначала сохраняем такой лог в рег сведений, а потом его очищаем когда он отправится в отдельную БД.

Аргумент со случайным удалением регистра слабый, ибо по такой логике можно вообще от них отказаться, а то вдруг погромисты удалят. Не вижу смысла в ссылке на документ, потому что придётся его копировать и лезть в базу искать. Не проще ли текст ошибки и запроса вставить в задачу, а там разработчик хоть на пустой базе постманом подёргает?

Целый документ для одной записи лога? Понимаю что на уровне таблиц разницы практически нет. Но есть же уровень "бизнес модели" решения и каких то "договоренностей по умлочанию". Давайте для логов планы обмена использовать. Одна запись - плюс один узел )) Че не то? Все равно таблица и ссылка есть ))) Вот прям не хотел бы я потом такие решения допиливать и на поддержку брать. Имхо. Лог это информация/сведение. И место ему либо в РС либо в журнале регистрации.

Удобства есть, но последняя фраза "возможно на любителя". Когда часто заходят джуны - масхэв, видимо. Тестировал запись логов в рс, справочник и документ (без кодов). В рабочее время до 20 входящих http запросов в секунду: json документы на 2-200-1000+ строк, справочники, рс. На одних и тех же данных вариант с РС до 2х раз быстрее, (справочники и доки отдельно не сравнивал, копейки) и пользователи субъективно счастливее.

@avbolshakov

2 жыл бұрын

Ничего не понял. Кто когда быстрее?

@eduard7190

2 жыл бұрын

@@avbolshakov согласен, разворачивать не было времени + 1 января сегодня ещё

Справедливости ради - ссылку коллеге можно скинуть и на запись РС.

@avbolshakov

2 жыл бұрын

через получить ссылку?

@Dustystec

2 жыл бұрын

@@avbolshakov да

@user-qe9ys3rd7q

2 жыл бұрын

@@avbolshakov ключ записи

Логи вроде всегда в журнал регистрации пишут. На крайняк во внешние файлы. Какие Логи вы в документе храните ??? Почему 1с этого не делает?

@yellow_club

2 жыл бұрын

Логи в журнале регистрации будет не удобно анализировать. В видео логировали все ответы от телеграмма. Для таких логов документ отлично подходит

@user-em7wb5ct2x

2 жыл бұрын

@@yellow_club простите, а чем неудобно анализировать? Отборы необходимые есть. Тем, что тормозит? Ну так это не динамический список для юзера чтобы им часто пользоваться и было так критично. Белые люди пишут в текстовые логи, но 1с-ники всегда найдут свой особый путь)

@evgeniuxp2evgeniuxp234

2 жыл бұрын

Журнал регистрации могут почистить 🤣 а в документах останется вся история за десятилетия и можно там найти кто 10 лет назад что передал или не передал и выявить проблему передачи 🤣

@romanfomin5653

2 жыл бұрын

@@user-em7wb5ct2x Журнал регистрации это утопия. Фиг что там найдешь.

@TheRamsvt

Жыл бұрын

@@user-em7wb5ct2x видел я эти логи "белых людей" в текстовых документах, в том числе и на 1с. Попытаться там найти что-то - та ещё задача. Ни отборов нормальных, ни сортировки. Очень удобно!

Есть же sentry или graylog

@yellow_club

2 жыл бұрын

Есть. А кто реально ими пользуется?

@TheL0z4

2 жыл бұрын

@@yellow_club тот кто хочет им пользоваться. ЖР + graylog явно будет меньше влиять на производительность системы чем РС и уж тем более документы.

@kuzyara555

7 ай бұрын

@@yellow_clubесть, пользуемся, а так же elk-стеком (необходимость в федеральных системах)

Извините, но это бред от автора, который, очевидно, не знает ничего про структуру хранения данных и вообще в целом платформу. Сколько же лишних, не используемых полей создается в БД, если это делать в документе. Кроме этого, про объектную модель и ссылку - тотальный бред. Во-первых, как часто вам надо "кидать" ссылку кому-то, чтобы тот поправил? Ты же залез в эту ошибку ты и правь. На даже если ты зачем-то лично инспектишь баг, а потом пересылаешь кому-то на исправление, то у РС есть КлючЗаписи, с помощью которого коллеге ровно так же можно кинуть ссылку на конкретную запись. Я уже молчу про "РС можно случайно удалить"... Клуб, ты суперский канал, но прошу, не надо инвайтить дилетантов, чтобы они распространяли свои навыки говнокодерства под видом бест-практик на всю аудиторию. Мне от этого больно :(

@user-rk5hy2tb1j

Жыл бұрын

Во-во. Даже если вдруг кто-то случайно удалит регистр - если ошибка действительно серьезная, то она повторится и обязательно попадет в лог еще раз, чего эти ошибки-то жалеть...

@kuzyara555

7 ай бұрын

согласен, это больше похоже на вредные советы. Еще бы про запись в текстовые файлы упомянули - было бы бинго) А по-промышленному, логи http запросов в мембране делаются (гуглить Membrane Service Proxy)

Хотя регистр сведений одна таблица и самая быстрая работа, но минусы следующие, у записей лога нет реквизитов которые можно натянуть на Измерения. Чем удобней документы это момент времени/уникальный номер, можно восстановить последовательность записи информации, по регистру сведений/справочнику нет такой возможности, время регистрации событий может быть одинаковым (ну или изобретать свой нумератор). Все сказанное относится к отладке HTTP, для остальных сценариев может быть не столь актуальным.

@priklyuchencher

2 жыл бұрын

УниверсальнаяДатаВМилисикундах поможет востановить последовательность, в большинстве случаев ее хватает

Честно говоря особо не принципиально, у рс есть плюс - там удобней индексы и проще конфигурировать свои, для отбора логов например, может пригодиться, у документов с этим похуже.

Док в режиме дебага , мысль интересная ... но как то и РС обходились раньше... кикнул его как описано в ролике за ненадобностью и освободил гиг другой..

А чего справочник уже до кучи не берете в расчет?

@yellow_club

2 жыл бұрын

Справочник для логов не подходит совсем

@mendicator4319

2 жыл бұрын

Чего

@egoras2283

2 жыл бұрын

@@yellow_club Чем справочник в этом случае отличается от документа?

@evgeniuxp2evgeniuxp234

2 жыл бұрын

@@egoras2283 , документы содержат отражения событий, а справочник - это другое. У нас в 77 всю зуп самописный делали через справочники и даже ссылочных реквизитов не было - т.к. ссылка тормозит 🤣 про регистры вообще молчу - их тоже не было совсем.

@mendicator4319

2 жыл бұрын

В БД эти таблицы равноценны, все отличие в количестве полей и индексов

Логировать в КХ надо

@kuzyara555

7 ай бұрын

ну хоть кто-то сказал это!

Тогда ещё лучше отключить автонумерацию и контроль уникальности, длина номера = 0. Чтобы не тратить время на присваивание номера .

@KroVladS

2 жыл бұрын

а если покопать чуть глубже, то выяснится что нифига не "тоже время" что и регистр

По такой логике вообще РС не нужны, есть же документы

@yellow_club

2 жыл бұрын

Есть сценарии, где РС предпочтительнее документа

@user-rk5hy2tb1j

Жыл бұрын

@@yellow_club И это как раз один из них.

Не убедительно с документом. РС наше все.

@evgeniuxp2evgeniuxp234

2 жыл бұрын

И в качестве измерения что? Нужен уникальный какой-то ключ, причем при каждой новой записи он новый должен быть и не записанный в регистр.