Все зависит от цели логирования, т.е. что хотите добиться?
Без относительно этого, чем легче будет фильтровать лог (т.е. больше машиночитаемых атрибутов) тем удобнее будет разрабатывать новые инструменты по его анализу. Т.е. анализировать plain text это дикий геморой.
Сохраняйте в логе как можно подробнее по полям (а может быть целую сложную структуру БД разработайте) что где когда и почему происходит.
p.s. пример лога - дублирование структуры базы данных, с добавлением новых ключевых полей, таким образом чтобы любое изменение в таблице порождало новую запись в логовой. Добавьте понятие пользовательская сессия и записывайте в каждую таблицу отдельным полем ее id (сессия это кто, с какой машины, когда залогинился, когда завершил работу) дополнительно дату изменения и собственно тип изменения (create/modify/delete). В некоторых случаях можно оптимизировать хранение данных, если modify записи будут хранить только измененные поля а delete - только идентификаторы, но работать с такой структурой сложнее.
Таблицы эти можно заполнять тригерами, код создания этой базы генерируется практически автоматически (чуть сложнее обновлять базу после правок структуры, но тоже реально). В качестве бонуса - вы сможете восстановить базу на любой момент времени (так как лог-база это фактически transaction log), только будьте аккуратны, после изменения структуры делайте полный бакап оригинала и храните навечно, иначе полное восстановление с начала истории может обойтись в копеечку.
Такая log-база данных это write once, позволяет подобрать технологии хранения максимально эффективные именно для этого. Никто не мешает на время анализа копировать интересующие данные в отдельную базу (in memory например, за последние сутки-неделю) и работать с этим подмножеством эффективнее. Однозначно напрашивается отдельное размещение базы на другом железе (как минимум другом диске).
p.s. совет, храните рядом с этой базой, в оперативной памяти (при включении компьютера ее можно восстановить из лога), слепок (а лучше много, по ключевым событиям) идентификаторов таблиц последних изменений (просто список id, например в виде таблицы {event_id, table_id, id_value}) тогда состояние на ключевые моменты сможете вытаскивать запросом с трудоемкостью O(1) а не n или n^2 (от количества изменений в таблице).
На основе этой лог-базы можно будет делать любые запросы, буквально решать любые задачи мониторинга, анализа, решения проблем с персоналом, и даже вандализма. Из недостатков решения - высокая избыточность по хранению данных, а так же высокая нагрузка на эту базу на запросы анализа, но можно заранее продумать в структуре партиционирование таблиц по времени, обычно в жизни любой системы есть периоды подведения итогов, ежегодные комплексные отчеты, и прочее, вот как минимум на эти периоды можно делить базу и отправлять устаревшие данные в архив.
Скорость роста такой базы на порядок выше (подобный подход использовался выборочно для некоторых таблиц в продакшне, сотни пользователей, 10-гигабайтная БД, лог - в 8 раз больше). Не жалейте места на дисках, оно дешевле чем проблемы, которые оно поможет решить.