2010-03-29 6 views
19

Мне нужно создать код на PHP, который позволит мне сохранить историю обновлений записей в базе данных MySQL, чтобы я мог найти по дате старую ревизию.Как сохранить историю обновлений записей в MySQL?

Вот пример того, что я хочу actualy для того чтобы достигнуть: http://en.wikipedia.org/w/index.php?title=Tunisia&action=history

Данные главным образом Числа, которые мы записываем о компании для создания отчетов и извлечения индексов.

Я планирую использовать codeigniter для его простоты, и я ищу идею о структуре или проекте с открытым исходным кодом, которые используют один и тот же подход для сохранения истории изменений в базе данных.

ответ

1

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

Таким образом, вам придется придерживаться аналогичного подхода. Каждый раз, когда данные изменяются, вам нужно будет выяснить, как данные изменились и сохранить данные «патча». Вероятно, вам лучше всего сохранить последнюю версию, а затем придется работать через все патчи, чтобы добраться до нее. Это означает, что вы будете иметь возможность увидеть что-то вроде

! created file 
* added data to cell D4 'product descript' D5 'set of pens' E5 '£5.99' 
* added data to cell D6 'toaster' E5 '£10' 
& changed data in cell D4 'Product Description' 

Каждое из этих изменений должны быть сохранены с отметкой времени или когда они где сделано. Вам также нужно будет разработать свою собственную схему для хранения изменений данных.

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

2

Вы должны использовать дополнительный слой между вашим приложением и db. Вы можете сделать очень просто самостоятельно (вместо прямого вызова mysql_query вы вызываете функцию, сделанную вами, которая обертывает ее и отслеживает обновления), или используйте некоторые существующие ORM. В псевдокоде

my_mysql_query($query){ 
    if($query is an update){ 
     //Log stuff before query 
    } 
    $r = mysql_query($query); 

    if ($r && $query is an update){ 
     //Log stuff after query 
    } 
    return $r; 
} 

И тогда в вашем приложении вы звоните my_mysql_query вместо mysql_query. Вы можете проверить, является ли таблица той, которую вы хотите отслеживать, и вы можете скопировать строку в копию исходной таблицы.

Если вы используете Doctrine ORM, вы можете использовать его Event Listeners, чтобы получить то, что вы хотите.

7

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

Всякий раз, когда вы делаете обновление в фактической таблице, вы также INSERT новую строку в таблице версий с дублирующимися данными. Всякий раз, когда вы хотите найти историю версий, все, что вам нужно сделать, это что-то вроде SELECT * FROM content_version WHERE id = CONTENT_ID ORDER BY version.

Если вы используете что-то вроде Doctrine ORM, у него есть поведение, которое делает это автоматически для прослушивателей событий.Вы можете это проверить здесь: http://www.doctrine-project.org/documentation/manual/1_2/en/behaviors#core-behaviors:versionable

+5

Почему бы не пойти так: 'main table' содержит только' id' и 'version_id'' version' таблица содержит все данные? – Shaheer

+0

Спасибо @Shaheer Я собираюсь попробовать это. – Eric

+0

@Shaheer, потому что большинство запросов относятся к текущим данным, поэтому разделение истории на отдельную таблицу гарантирует, что эти запросы не получают штрафа за производительность, поскольку таблица становится * n * раз такой же большой. Как большой * n * будет зависеть от того, как часто обновляются записи. –

1

Если я правильно понял, вы сохраняете только «число» в определенной таблице и хотите просмотреть историю изменений этого номера?

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

Простой способ сделать это, имея таблицу со следующими полями:

  • идентификатор
  • CompanyID
  • номер
  • метка времени

Если вы хотите знать, текущий номер, просто

SELECT * FROM table WHERE companyId = X ORDER BY timestamp DESC LIMIT 1 

Если вы хотите увидеть все изменения, просто сделать:

SELECT * FROM table WHERE companyId = X 
+0

Это приборная панель, которую я пытаюсь перенести из простого файла Excel. Поскольку я не знаком с ORM, я предпочитаю писать свой собственный код. – Proxium

+0

Что может быть хорошей штукой :) –

+1

SELECT * FROM table WHERE companyId = X ORDER BY timestamp DESC LIMIT 1 – DarkSide

15

Самое простое решение (в зависимости от ваших конкретных потребностей), вероятно, будет добавить на обновление/вставка/удаление триггера в таблицу, так что вы может выполнять дополнительное ведение журнала, когда данные вставлены/обновлены/удалены. Таким образом, даже ручные вмешательства на db будут покрыты ...

Для получения дополнительной информации отметьте http://dev.mysql.com/doc/refman/5.1/en/triggers.html.

6

Существует среда с открытым исходным кодом (MIT license) для создания CRM и ERP-типа управляемых базой данных веб-приложений. Вы можете скачать EPESI из http://epe.si/ доступны также на SourceFroge: http://sourceforge.net/projects/epesi/

EPESI-х CRUD двигатель - Record Browser - имеет очень эффективную историю записи, а также другие функции, такие как передовые системы разрешений (вплоть до поля уровень) и многое другое.

В одном наборе записей хранятся данные из целых 10 таблиц, и это агностик базы данных (использует PHPAdoDB). Таблица recordset_data хранит «необработанные» данные и историю изменений хранится в 2 дополнительных таблицах: recordset_edit_history и recordset_edit_history_data.edit_history

Record имеет следующую структуру:

  • ID (первичный ключ для этой таблицы, индекс)
  • редактировал (временную метку: 2008-05-14 15:18:15)
  • Edited по: (идентификатор пользователя) edit_history_data

Record имеет следующую структуру:

  • edit_id = Идентификатор из истории редактирования
  • поля = имя поля, которое было изменено
  • old_value = значение поля, которое изменило.

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

Смежные вопросы