Структура таблицы MySql

Question

На данный момент у меня есть таблица в mysql, которая записывает транзакции. Эти транзакции могут обновляться пользователями - иногда никогда, иногда часто. Однако мне нужно отслеживать изменения для каждого поля в этой таблице. Итак, на данный момент я имею в виду поле TINYINT (1) в таблице с именем «is_deleted», а когда транзакция «обновляется» пользователем, она просто обновляет поле is_deleted до 1 для старой записи и вставляет новый запись.

Это все работает хорошо, потому что я просто должен выполнить следующую инструкцию SQL, чтобы получить все текущие записи:

SELECT id, foo, bar, something FROM trans WHERE is_deleted = 0; 

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

Это значит, что записи обновления будут занимать немного больше времени, так как будут запущены 3 запроса: 1. INSERT INTO trans_deleted old record; 2. УДАЛИТЬ от trans WHERE id = 5; 3. INSERT INTO trans новые записи

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

Любые мысли по этому поводу?

Answer 1

Я хотел бы предложить таблицу транс и table_revision

Где транс имеет поле идентификаторов и current_revision и пересмотра имеет поле идентификатора, ТрансИД, foo и бар.

Чтобы получить все текущие элементы, то:

SELECT r.foo, r.bar FROM trans AS t 
    LEFT JOIN revision AS r ON t.id = r.trans_id 
    WHERE t.current_revision = r.id 

Если теперь ставить индексы r.id и r.trans_id архивирования woun't сделать это намного быстрее для вас.

Answer 2

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

Существует еще один: вы также должны учитывать время программиста, а не только время процессора. Если вы сохраняете архивные строки в одной таблице с живыми, вам придется помнить и позаботиться об этом в каждом запросе, который вы выполняете в этой таблице. Не говорить о будущих программистах, которым, возможно, придется иметь дело со столом ... Я бы рекомендовал подход к архивированию, основанный только на этом факте, даже если бы не было никакого улучшения скорости!