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

Question

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

Итак, человек A пишет статью 1 и сохраняет ее. Лицо B редактирует статью 1.

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

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

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

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

Answer 1

Вы можете указать одну и ту же статью в одной таблице, но с другим значением ID. Вы можете определить активную статью на основе самого высокого идентификатора или путем установки логического значения, такого как «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 2

Путь wikipedia заключается в том, что он имеет одну таблицу, IIRC называется «cur», которая содержит только текущую версию каждой статьи и вторую таблицу, содержащую все предыдущие версии.

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

Answer 3

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) 

Answer 4

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

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

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

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