Обновляет таблицу с MySQL правильно - PullRequest
Новая
       6

Обновляет таблицу с MySQL правильно

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

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

Я в основном собираю некоторую информацию из API и сохраняю ее в MySQL.

Первая таблица - "stati c", она захватывает информацию один раз и никогда не обновляется (если элемент не будет удален), а затем другие 2 обновляются ежедневно.

1-я таблица: 

ID |    added_date    |   removed_date   |     url     | status
---|------------------|------------------|-------------|-------
 1 | 15/01/2020 21:00 |       NULL       | http://xxx  |   1
 2 | 25/01/2020 18:00 | 29/01/2020 15:00 | http://xxx2 |   2
 3 | 17/02/2020 10:00 |       NULL       | http://xxx3 |   1

Status 1 = Active
Status 2 = Inactive

Если что-то изменится, следующие 2 таблицы обновляются по мере необходимости. Это включает в себя изменения в заголовке / описании, новом количестве просмотров / рейтинге / комментариях или добавленных / удаленных тегах

2-я таблица: (хранить почти всю дополнительную информацию) 

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

mid = main's table ID

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

3-я таблица: 

ID | mid | tag_id |    added_date    |   removed_date
---|-----|--------|------------------|------------------
 1 |  1  |    2   | 15/01/2020 21:00 |      NULL
 2 |  1  |    3   | 16/01/2020 16:30 | 18/01/2020 13:00
 3 |  2  |    3   | 25/01/2020 18:00 |      NULL
 4 |  3  |    5   | 17/02/2020 10:00 |      NULL
 5 |  1  |    5   | 11/02/2020 17:00 |      NULL

1 Ответ

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

Нет хорошей или плохой структуры, если вы не показываете бизнес-правила вашей системы.

Существует множество привычек / практик структурирования таблиц для модификации / удаления данных. Для вашего примера это зависит от того, какие данные предполагается использовать наиболее часто. Эти данные вы упаковываете в одну таблицу, а другие (extra_info) во вторую, как и вы.

У меня есть только две личные проблемы, о которых я хочу упомянуть. Во-первых, вы пропустили статус в 3-й таблице. Когда у вас есть removed_date, также должен быть статус Boolean / Int. Это сокращает время запросов. Вы сделали то же самое в 1-й таблице.

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

...