Правильное хранение изменений в базе данных MySQL - PullRequest
Новая
       4

Правильное хранение изменений в базе данных MySQL

1 голос
/ 01 апреля 2020

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

Моя первая таблица содержит основную c информацию, а вторая и третья - дополнительные записи, которые я собираю каждые 8 ​​часов.

ID | creation_date | removal_date | article_url | status, которые в основном являются наиболее стабильными записями. Состояние и дата удаления - единственные, которые изменятся в случае, если мы отключим / удалим запись.

Пример: 

ID |  creation_date   |   removal_date   | article_url | status
---|------------------|------------------|-------------|-------
 1 | 10/01/2020 20:00 |       NULL       | http://xxx  |   1
 2 | 23/01/2020 10:00 | 27/01/2020 13:00 | http://xxx2 |   2
 3 | 10/02/2020 15:00 |       NULL       | http://xxx3 |   1

Status 1 = Active
Status 2 = Inactive

Вторая таблица содержит все остальное: ID | main_id | last_update | title | description | views | rating | comments

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

Пример: 

ID | main_id |    last_update   |      title     |    description     | views | rating | comments
---|---------|------------------|----------------|--------------------|-------|--------|---------
 1 |    1    | 10/01/2020 20:00 | First Article  | Description..      |   1   | 1 | 0
 2 |    2    | 23/01/2020 10:00 | Second Article | Desc..             |   1   | 1 | 0
 3 |    1    | 11/01/2020 20:00 | First Article  | Description update |   15  | 3 | 2
 4 |    1    | 12/01/2020 20:00 | 1st Article    | Description update |   30  | 5 | 4
 5 |    3    | 10/02/2020 15:00 | 3rd Article    | Descript!          |   3   | 1 | 1

В третьей таблице содержатся теги: ID | main_id | tag_id | date_added | date_removed

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

Пример: 

ID | main_id | tag_id |    date_added    |   date_removed
---|---------|--------|------------------|------------------
 1 |    1    |    2   | 10/01/2020 20:00 |      NULL
 2 |    1    |    3   | 15/01/2020 16:30 | 17/01/2020 13:00
 3 |    2    |    3   | 23/01/2020 10:00 |      NULL
 4 |    3    |    5   | 10/02/2020 15:00 |      NULL
 5 |    1    |    5   | 11/02/2020 17:00 |      NULL

Я просто хотел бы знать, есть ли лучший / более правильный способ хранения вышеуказанных данных.

1 Ответ

0 голосов
/ 01 апреля 2020

Yepp, @Maria, понятнее. Предполагая, что вы имеете дело с записями в блоге, у вас может быть такая модель данных. 

Table 1.  articles. // where every article is created.

article_id | article_creation_date | article_title | article_url | article_creator_id | article_description          |
-----------|-----------------------|---------------|-------------|--------------------|------------------------------|
1          | 2020/03-31 10:36:05   | "The Dilemma" | /articles/1 | 23                 | Explains the relations....|

Таблица 2. article_status // сохраняет изменения состояния для каждой статьи. 

article_status | article_id | status | date_of_change     |
---------------|------------|--------|--------------------|
1              |  1         | 7      | 15/04/2020 09:30:00|

Таблица 3. article_tags. // каждая статья и ее теги 

article_tag | article_id | tag_id | date_added         |
------------|------------|--------|--------------------|
1           |  1         | 24     | 15/04/2020 09:30:00|

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

article_v_id | article_id | views_summarized | time_lapse     | time_lapse_value | date_summarization |
-------------|------------|------------------|----------------|-------------------|-------------------|
1           |  1          | 1578             |  Day           | 10/04/2020        | 12/04/2020 13:27:04  |

Таблица 5. article_updates // хранит изменения / обновления, внесенные в каждую статью. 

article_update_id | article_id | type_of_update | update_detail | update_author | date_of_update         |
------------------|------------|--------------------------------|---------------|------------------------| 
1                 |  1         | Title          |               |    John Doe   | 19/04/2020 15:27:24    |

И содержимое обновления сохраняется непосредственно в таблице статей, скажем, смена заголовка. Нет необходимости хранить все измененные заголовки, контент. Просто событие и кто внес изменения.

...