Журнал активности базы данных MySQL: поля против таблицы

Question

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

Теперь, насколько я могу видеть, что есть два подхода к реализации что-то вроде этого:

1. Создать «обновленные» поля для всех таблиц, которые я хочу, чтобы отслеживать, а затем позволить MySQL обновить эти поля для меня (о предложении UPDATE)

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

Теперь кажется, что 1-й подход будет иметь преимущество в том, чтобы держать вещи простыми и удобными в обслуживании. Однако как это повлияет на производительность, если я вдруг решит получить каждый журнал в базе данных для обзора. Кроме того, это вроде бы идет вразрез с нормализацией (но не очень) с теми же данными, хранящимися в нескольких таблицах.

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

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

Есть ли примеры реальной жизни, в которых используются оба подхода: ?

И:

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

Answer 1

Это зависит от того, какая информация вам нужна и ваша текущая архитектура.

Если вы просто хотите узнать дату последнего обновления, необходимо иметь 2 поля (дату создания и последнее обновление). Это связано с тем, что отдельная таблица не даст никакого повышения производительности, но сделает ваш код сложнее в обслуживании.

Это еще одна история, если вы хотите иметь что-то более сложное, например, сообщать о различиях (что было изменено) и/или иметь полный журнал изменений для каждой транзакции (может быть, несколько обновлений для одной транзакции, верно?). В этом случае у вас на самом деле должна быть отдельная таблица, потому что иначе она раздувает ваш стол и уменьшает производительность.

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

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

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