Как организовать таблицу достижений на сайте?

Question

[Muranx]

Здравствуйте!

Идея проста, есть таблица user

+----+-----------+
| id | user_name |
+----+-----------+
|  1 | Dima      |
|  2 | Sveta     |
|  3 | Katya     |
|  4 | Jenya     |
+----+-----------+

Нужно сделать таблицу достижений, которая будет связана с пользователями из таблицы user к примеру по id и которая будет хранить в себе достижения пользователей в программе обучения на сайте! первое что приходит в голову учитывая мой 3х недельный опыт изучения скл это ....

+-----------------+----------+----------------+-----------------+---------------+
| achievements_id | users_fk | pass_first_lvl | pass_second_lvl | invite_friend |
+-----------------+----------+----------------+-----------------+---------------+
|               1 |        1 |              1 |               0 |             1 |
|               2 |        2 |              0 |               0 |             1 |
|               3 |        3 |              1 |               0 |             0 |
|               4 |        4 |              0 |               0 |             1 |
+-----------------+----------+----------------+-----------------+---------------+

... где разумеется achievements_id это первичный ключ, а users_fk это внешний ключ связанный с таблицей user по полю id, там где в ячейке 1 разумеется достижение получено , ну а там где 0 что бы вы думали...? достижение ещё не выполнено ! Но сразу встаёт вопрос :

1. Как быть , если ачивок будет больше чем 4 ( а их 100% будет больше чем 4), например 100 достижений, это же получится таблица монстр?

Далее... Разумеется золотым стандартом ачивок является дата, когда они получены (ну допустим чтобы в дальнейшем использовать эту дату в каком-то общем рейтинге), есть идея....

+-----------------+----------------------+---------------------+----------------------+--------------------+
| achievements_id | achievements_date_fk | pass_first_lvl_date | pass_second_lvl_date | invite_friend_date |
+-----------------+----------------------+---------------------+----------------------+--------------------+
|               1 |                    1 | 2021-12-05          | 0000-00-00           | 2020-04-01         |
|               2 |                    2 | 0000-00-00          | 0000-00-00           | 1987-11-03         |
|               3 |                    3 | 2011-05-05          | 0000-00-00           | 0000-00-00         |
|               4 |                    4 | 0000-00-00          | 0000-00-00           | 2019-07-16         |
+-----------------+----------------------+---------------------+----------------------+--------------------+

.. ещё одна таблица - монстр с датами этих ачивок, которая соединена с таблицей user по id
В общем главный вопрос тут думаю про реализацию структуры бд, и на сколько это разумная идея организовывать таблицы достижений именно так, как Я с высоты своего опыта ( -_- ) ? Спасибо, за внимание, будьте корректны и не занудничайте через-чур !

Comments

[Ипатьев]

пишется "чересчур"

Answer 1

[galaxy]

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

+-----------------+----------+----------------+-----------------+
| achievements_id | users_fk |      type      |      date       |
+-----------------+----------+----------------+-----------------+
|               1 |        1 |              1 |      2021-10-01 |
|               2 |        2 |              1 |      2021-10-04 |
|               3 |        1 |              2 |      2021-10-08 |
|               4 |        1 |              4 |      2021-10-15 |
+-----------------+----------+----------------+-----------------+

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

+-----------------+-----------+----------------+-----------------+
| achieve_prop_id | acieve_fk |      type      |      value      |
+-----------------+-----------+----------------+-----------------+
|               1 |         1 |              1 |           'abc' |
|               2 |         2 |              1 |           '145' |
+-----------------+-----------+-----------------+----------------+

Comments

[Muranx]

хм, если я вас правильно понял, то поле achievements_id не является уникальным? Т.е. примерно так :

+-----------------+----------+----------------+-----------------+
| achievements_id | users_fk |      type      |      date       |
+-----------------+----------+----------------+-----------------+
|               1 |        1 |              1 |      2021-10-01 |
|               1 |        2 |              1 |      2021-10-04 |
|               1 |        3 |              2 |      2021-10-08 |
|               2 |        6 |              4 |      2021-10-15 |
+-----------------+----------+----------------+-----------------+

чтобы узнать какие юзеры выполнили эту ачивку нужно (выражаясь языком маглов) найти нужный achievements_id и проверить, есть ли для этого айди нужный нам users_fk.. так? Просто ваша первая таблица в качестве примера побуждает немой вопрос, как мне для одной ачивки добавить несколько юзеров , которые её выполнили?

[galaxy]

Muranx, если вы хотите ачивки выделить в отдельную сущность, то это уже связь многие-ко-многим (т.к. у юзера может быть много ачивок и одну ачивку могут выполнить много юзеров). Связь тогда такая (через промежуточную таблицу achieve_user_connection):

achievements:
  achievements_id
  type
  ... (other properties)

achieve_user_connection:
  conn_id (primary key)
  user_fk
  achieve_fk
  date
  ...

[Ипатьев]

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

[Ипатьев]

я думаю в ответ надо просто добавить таблицу achievement_type, в которой будут все эти pass_first_lvl_date

[Muranx]

galaxy, т.е. есть таблица с пользователями :

+----+-----------+
| id | user_name |
+----+-----------+
|  1 | Alex      |
|  2 | John      |
|  3 | Bob       |
|  4 | Charli    |
|  5 | Tom       |
+----+-----------+

есть таблица с инфой об ачивках

+-----------+--------------+
| ach_id_pk | ach_name     |
+-----------+--------------+
|         1 | get_up       |
|         2 | clean_tooths |
|         3 | make_up      |
+-----------+--------------+

и есть таблица которая показывает какие пользователи выполняли какие ачивки, т.е. реализация связи "многие - ко - многим", так?

+------------+-----------+
| user_id_fk | ach_id_fk |
+------------+-----------+
|          1 |         1 |
|          2 |         1 |
|          3 |         1 |
|          5 |         1 |
|          2 |         2 |
|          3 |         2 |
|          1 |         3 |
|          5 |         3 |
+------------+-----------+

[Ипатьев]

Muranx, так, только вы же ещё дату хотели? и фактически у вас получится таблица из ответа

[Ипатьев]

только teeth, а не "tooths" :)

[Muranx]

Роман Юрьевич Ипатьев, хм, ну дату получается можно добавить в эту среднюю связующую таблицу! наверное... :D Вообще мне пока сложно это по той причине, что нет чёткого понимания про эти типы связей, и когда и где их использовать в реальной жизни, хотя статьи я читал, да и вторая проблема, это "предусмотреть всё" , с ней у меня особый диалог в программировании! :D Я вроде уже и планы пишу, расписываю что и как будет, а всё равно по ходу написания кода ".... ть забыл.."

[Ипатьев]

Muranx, да там ничего сложного. просто надо помнить несколько простых правил. Например, "все списки хранятся вертикально, а не горизонтально", или "если какая-то сущность используется в другой таблице, то её представляет её id".
И тогда все эти связи получаются простой логикой.
вот у нас и получилась простая таблица достижений, просто и юзер и ачивка представлены своими id

[galaxy]

Роман Юрьевич Ипатьев,

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

мне не нужно определяться, это автору вопрос, хочет ли он видеть отдельно сущность "ачивки".

[Ипатьев]

galaxy, ну нет, это не к автору, а как раз к вам. потому что отдельно сущность ачивки очевидно диктуется той самой нормальной формой, про которую вы так назидательно втолковывали автору :)
не говоря уже о том что она в вашем вопросе присутствует, в виде, почему-то "типа"

[galaxy]

Роман Юрьевич Ипатьев, ну а в чем проблема? Если у ачивки нет никаких свойств, кроме типа, то зачем выносить ее в отдельную таблицу? Это уже нормализация ради нормализации

[Ипатьев]

galaxy, хотя бы в том что название может поменяться