SysDatabaseLog, поле UserName

[dim-gin]

Доброе время суток, товарищи!

DAX 2009, kernel build 1600.3596.

Кто-нибудь в курсе, зачем в 2009й к журналу БД аксапты (SysDatabaseLog) привинтили 140-символьное поле UserName (пусть и с конф.ключом)? В трёшке такого не было. Я посчитал в столбик: допустим будет регулярно заполняться в среднем только 70 символов из 140, получаем на 1 млн записей прибавку в занимаемом только данными пространстве около 0,13 Гб. Вкупе с включённым CreatedBy я немного не понимаю смысла этого явления (ведь можно обойтись джойном).

Мудрые мира аксапты, просветите: есть ли скрытый смысл в таком хранении информации о пользователе (при допущении, что UserInfo.Id в системе никогда не будет переименовываться или удаляться)?

Или я совсем некорректно считаю потребляемое место (фактическое резервирование экстентов под данные и прочие тонкости ms sql)?

[ice]

у нас SysDatabaseLog - 500млн строк, 300Гб.
о какой экономии у вас идет речь?

[dim-gin]

Если считать, что моё умножение в столбик более менее корректно, то для Вашего примера получаем 0.13 х 500 = 65 Гб. Это не очень много в размере базы, но и не совсем мизер. Хренилище-то не резиновое...

Просто сабж является одним из рекордсменов по размеру ежедневного прироста. Поэтому возник вопрос, а нет ли там ненужных полей.

[ice]

Отключите журналирование, там где нет необходимости. А далее очищайте устаревшие строки. Таблицу логов можно разместить на большой и медленный диск

[dech]

Цитата:

Сообщение от dim-gin

Доброе время суток, товарищи!

DAX 2009, kernel build 1600.3596.

Кто-нибудь в курсе, зачем в 2009й к журналу БД аксапты (SysDatabaseLog) привинтили 140-символьное поле UserName (пусть и с конф.ключом)? В трёшке такого не было. Я посчитал в столбик: допустим будет регулярно заполняться в среднем только 70 символов из 140, получаем на 1 млн записей прибавку в занимаемом только данными пространстве около 0,13 Гб. Вкупе с включённым CreatedBy я немного не понимаю смысла этого явления (ведь можно обойтись джойном).

Мудрые мира аксапты, просветите: есть ли скрытый смысл в таком хранении информации о пользователе (при допущении, что UserInfo.Id в системе никогда не будет переименовываться или удаляться)?

Или я совсем некорректно считаю потребляемое место (фактическое резервирование экстентов под данные и прочие тонкости ms sql)?

Поле встречается только в отчете и методе insert(). Если вы программно запретите удалять пользователей, то можете заменить Username кодом пользователя. Иначе вы рискуете потерять в логах некоторых ключевых пользователей, которых могли пересоздать с другим id либо вообще удалить из системы. Так хотя бы имя увидите.