Записывается в SQL плохая практика?

Question

Я работаю в компании eCommerce. Наш администратор баз данных недавно сказал мне, что использование SQL для ведения журнала - это плохая практика, и вместо этого рекомендуется использовать плоский файл и grepping. Я никогда не слышал, что регистрация в SQL была плохой практикой, и я не нашел ничего, что подтвердит это.

Когда я говорю о регистрации, я имею в виду протоколирование действий пользователя, таких как вход в систему, изменение информации учетной записи и т. Д., А также данные, такие как их пользовательский агент, IP-адрес, идентификатор учетной записи и информация о событиях.

Хотя с течением времени это приведет к множеству рядов, это позволяет очень легко искать, если есть проблема с клиентом.

Записывается в SQL плохая практика, и предпочтительнее ли регистрироваться в файле?

Спасибо.

Answer 1

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

Вы можете добавить немного больше структуры в свои журналы с SQL по сравнению с плоскими файлами. Например, вы могли бы иметь следующие столбцы:

• ID
• DateTime
• EventCode
• Сообщение
• MachineName
• HttpRequestID
• UserName
• Идентификатор_пользователя
• AdditionalDataXML: запрашиваемый XML-столбец со структурированными данными о событии

Очень удобно. Я рекомендую это.

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

В качестве смягчения вы можете иметь ночной TRUNCATE TABLE очистить элементы журнала. Возможно, экспортируйте их перед этим (bcp.exe).

Answer 2

Возможно, он имел в виду использование триггеров для регистрации as bad practice. Триггеры могут вызывать множество неожиданных эффектов и могут считаться плохой практикой.

Помимо этого SQL обычно используется как хранилище для журналов, поэтому (при условии, что у вас достаточно памяти) нет ничего плохого в этом.

Answer 3

Я до сих пор не слышал, как он описывался как «плохая практика», и вы всегда можете настроить работу, чтобы очистить записи за определенный возраст (например, мы сохраняем только журналы в прошлом месяце). Я думаю, это также зависит от того, кто будет просматривать журнал, поскольку не все сотрудники службы поддержки приложений знают SQL, тогда как они могут легко читать текстовый файл.

Answer 4

Существует проблема с транзакциями.Ведение журнала будет частью транзакции, поэтому, если он будет откат, журнал также исчезнет.

Для входа в SQL для работы вам необходимо настроить отдельный сеанс СУБД, который усложнит ситуацию. Плоские файлы не имеют транзакций. Они также терпят неудачу (разумно) изящно на условиях полного диска. И вы можете управлять ими (чистить), не мешая транзакциям.

И, поскольку регистрация в основном контрольно-измерительная аппаратура, хорошо не мешать больше, чем необходимо при контролируемом процессе.

И наконец: если вы действительно хотите упростить использование SQL, вы всегда можете выбрать повторный импорт flatfiles в таблицу СУБД. В отдельной транзакции.

BTW: вышеупомянутый ответ не касается поддержания история. Это совершенно другой мяч, который следует считать частью приложения СУБД +.

Answer 5

Похоже, что ваш администратор базы данных скорее всего запустит все протоколирование (SQL или приложение) в плоский файл, чтобы использовать grep. Я не согласен полностью. Я лично считаю, что SQL намного проще искать, чем использовать grep. Предложение

WHERE event_time BETWEEN '1/1/2012 1:00AM' AND '1/1/2012 1:10AM' 

намного проще писать и быстрее получить (при условии индексации), чем все, что вы собираетесь получить от Grep.

Microsoft не считает, что ведение журнала плохо к БД, их Enterprise Library поддерживает его: http://msdn.microsoft.com/en-us/library/ff664543(v=pandp.50).aspx

И IIS поддерживает его, а также и большинство крупных библиотек протоколирования включают поддержку баз данных.

Проблема с хранением данных не обязательно сама по себе, вы либо собираетесь регистрироваться в файле в своем приложении, либо регистрироваться в файле DB в своей базе данных. Основные проблемы, которые я вижу, это то, является ли это чрезмерно дорогостоящим, когда вы делаете свои транзакции, и, как упоминалось выше, проблема, связанная с откатой транзакции, приводит к откату от записи.