Отдельная производственная база данных для ведения журнала

Question

У меня есть тестируемое приложение, которое регистрирует события для ведомственного приложения Windows формы в базе данных SQL Server. Приложение почти готово к производству. База данных журналов полностью отделена от базы данных приложения.

У меня вопрос: действительно ли мне нужно создавать рабочую версию базы данных журналов или я могу просто регистрировать производственные и тестовые события в одной базе данных? Очевидный ответ - да, конечно, мне нужна отдельная база данных. Вы никогда не хотите смешивать тестовые и производственные среды. Но в этом случае данные, записываемые в базу данных, на самом деле не являются производственными данными, а просто регистрируют детали, которые мы используем для устранения проблем. Это не имеет никакой коммерческой ценности, и ничего существенного не будет потеряно, если данные будут случайно удалены или база данных будет временно недоступна. И все это в тестовой среде значительно облегчит мне управление.

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

Answer 1

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

Плюс, что если вы решите изменить процесс регистрации? Пока вы занимаетесь новой разработкой, весь процесс разработки может прерваться.

И будут случаи, когда кто-то может читать логи, паникуйте при какой-то ошибке, забывая, что это произошло в dev. Или, что еще хуже, кто-то может увидеть плохую ошибку, которая, как он думал, происходит в dev, которая действительно происходит в prod.

Answer 2

Я не вижу ничего плохого в том, чтобы держать его в окне разработчика, , если ваше приложение не будет работать, если оно не сможет правильно войти в систему, или если информация, которая будет зарегистрирована, более ценна, чем вы указываете. 1003 *

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

Answer 3

Я бы сказал:

Используйте стандартную методологию ведения журнала (одну DLL или аналогичную) и фактически размещайте базу данных журналирования в рабочем состоянии.

Таким образом, ваша база данных журналов может рассматриваться как «Сервер журналирования», и ВСЕ приложения (Dev, Staging, Test и Prod) могут регистрироваться на ней, поскольку вы используете проверенную библиотеку.

Конечно, вы все равно должны остерегаться того, что вы не заполняете сервер ...

Answer 4

Ведение журналов в базе данных - плохая идея. Что происходит, когда вы не можете подключиться к БД по тем или иным причинам? Я предлагаю вам использовать log4net и реализовать RollingFileAppenders. Они записывают записи журнала в файл, и когда размер файла достигает определенного предела, log4net начинает запись в новый файл. Если у вас есть вопросы по настройке, не стесняйтесь спрашивать. Буду рад помочь!