Структурирование месячных данных в SQL

Question

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

Например, если у меня была таблица пользователей, в которой я пытался сохранить 3 разных значения: имя, адрес электронной почты и сколько раз они входили в систему каждый месяц. Не лучше ли создавать новый столбец для каждого месяца и хранить количество раз, которое они выполнили в этом месяце, под этим столбцом? Или лучше создать новую строку / таблицу для каждого месяца?

Мой инстинкт говорит, что создание новых столбцов - лучший способ уменьшить избыточность, однако я вижу, что это становится немного громоздким, когда количество столбцов в таблице меняется со временем. (Я также подумал, что если бы я делал это по столбцам, было бы оправданно иметь total_column, который отслеживал все месяцы за раз).

Спасибо!

Answer 1

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

PK: UserID & Date или Новый столбец (например, RowNo с автоматическим приращением)

+--------+------------+-----------+
| UserID |    Date    | NoOfTimes |
+--------+------------+-----------+
|     01 | 2018.01.01 |         1 |
|     01 | 2018.01.02 |         3 |
|     01 | 2018.01.03 |         5 |
|     .. |            |           |
|     02 | 2018.01.01 |         2 |
|     02 | 2018.01.02 |         6 |
+--------+------------+-----------+

Или

PK: UserID, Year & Month или Новый столбец (например, RowNo с автоматическим приращением)

+--------+------+-------+-----------+
| UserID | Year | Month | NoOfTimes |
+--------+------+-------+-----------+
|     01 | 2018 | Jan   |        10 |
|     01 | 2018 | feb   |        13 |
+--------+------+-------+-----------+

Прежде чем создавать таблицу, ознакомьтесь с нормализацией базы данных. Особенно 1-й (1NF), 2-й (2NF) и 3-й (3NF) формы нормализации.

• https://www.tutorialspoint.com/dbms/database_normalization.htm
• https://www.lifewire.com/database-normalization-basics-1019735
• https://www.essentialsql.com/get-ready-to-learn-sql-database-normalization-explained-in-simple-english/
• https://www.studytonight.com/dbms/database-normalization.php
• https://medium.com/omarelgabrys-blog/database-normalization-part-7-ef7225150c7f

Answer 2

Любой подход действителен, в зависимости от шаблонов запросов и требований к соединению.

Одна строка за каждый месяц

Для пользователя строка, содержащая количество логинов за месяц, будет вставлена, когда данные будут доступны за месяц. Там будет 1 строка в месяц на пользователя. Этот дизайн облегчит создание соединений по столбцу month. Однако для получения данных для пользователя за год потребуется несколько строк.

-- column list
name
email
month
login_count

-- example entries
'user1', 'user1@email.com','jan',100
'user2', 'user2@email.com','jan',65
'user1', 'user1@email.com','feb',90
'user2', 'user2@email.com','feb',75

Одна строка для всех месяцев

Вам не нужно динамически добавлять столбцы, так как количество месяцев известно заранее. Таблица может быть изначально создана для размещения всех месяцев. По умолчанию все столбцы month_login_count будут инициализированы равными 0. Затем строка будет обновляться по мере заполнения счетчика за месяц. Там будет 1 строка на пользователя. Этот дизайн не лучший для выполнения объединений month. Однако для получения данных о пользователе за год потребуется только одна строка.

-- column list
name
email
jan_login_count
feb_login_count
mar_login_count
apr_login_count
may_login_count
jun_login_count
jul_login_count
aug_login_count
sep_login_count
oct_login_count
nov_login_count
dec_login_count

-- example entries
'user1','user1@email.com',100,90,0,0,0,0,0,0,0,0,0,0
'user2','user2@email.com',65,75,0,0,0,0,0,0,0,0,0,0

Answer 3

На мой взгляд, лучший подход - хранить каждый логин для каждого пользователя.

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

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

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