Нет таблицы базы данных удаления

Question

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

Итак, человек А пишет статью 1 и сохраняет ее. Человек Б редактирует статью 1.

Как лучше организовать эту базу данных? Мои мысли:

• статьи
• Статьи
• ID
• old_id (идентификатор статьи перед редактированием, чтобы пользователь мог «отменить»),
• удалено (логическое значение, если удалено, оно не будет отображаться в системе, если пользователь не просмотрит «корзину»),
• название
• статья
• создано (избыточно?),
• обновлено (дата последнего обновления),
• user_id (идентификатор пользователя, который последний раз обновлял статью).

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

Это лучший способ сделать это или есть более эффективный способ?

Answer 1

То, как в Википедии это делается, состоит из одной таблицы, IIRC, называемой "cur", которая содержит только текущую версию каждой статьи, и второй таблицы, содержащей все предыдущие версии.

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

Answer 2

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

Это похоже на то, как SO и Wikipedia обрабатывают историю изменений.

PK | ID  |        Title         |        Text       |   Edited   | Edited By
-----------------------------------------------------------------------------
1  | 128 | History of Computin  | The History of... | 2009/07/10 | Jon Sampson
2  | 128 | History of Computing | The History of... | 2009/07/11 | John Smith

В этом случае я вижу, что статья 128 была отредактирована. Самая новая версия - №2 Джона Смита.

Answer 3

Да, я бы пошел на это. Столбец состояния с «A» (активным), «D» (удаленным), «P» (в ожидании одобрения редактора) и т. Д.

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

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

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

Answer 4

TABLE Revisions:
 ID
 FK_Articles (Articles.ID)
 Status (active, deleted, etc)
 Content
 Metadata (timestamp, user data, etc)

TABLE Articles:
 ID
 FK_Revisions (Revisions.ID - current revision of the article)