Есть ли необходимость в unsigned integer id для one to one отношений?

Question

[codercat]

Есть таблица юзеров (users), есть таблица с полями-счётчиками (user_counts)

users обычная как у всех
user_counts с полями: id, user_id, comments, likes, votes, notifications

UPD: user_id -- уникальный, не может быть 2 записи user_counts с одинаковым user_id

Интересно насколько необходим unsigned integer id для таблицы user_counts, если всё равно все выборки/обновления происходят по user_id? Возможно, он помогает каким-то внутренним операциям движка бд происходить быстрее или можно убирать?

Answer 1

[Therapyx]

Это обычная практика при проэктировании таблиц. Есть primary key и есть foreign key. В данном случае user_id в таблице. Первичный ключ должен быть всегда "уникален". Если не айди, то что тогда возмешь ты как уникальность всех строк? В противном случае придется брать comments или Likes или votes или notifications или же комбинации из них. Но где гарантии, что не попадется 2 одинаковые комбинации к примеру из коммента и нотификации.? Да и ставить ключ с тем же комментом ххх символов? ))
Надеюсь разьяснил внятно )

Comments

[codercat]

Так user_id в user_counts уникальный. One to One, не может быть 2 записи user_counts с двумя одинаковыми user_id

[Therapyx]

user_id в user_counts это foreign key, который должен быть по идее связан в sql логике.
возмем к примеру более нормальную реализацию:
- забудь про множественное число, каждый комментарий это одна строка со своим уникальным айди, который привязан в user_id
например в users - user_id = 1
Таблица комментариев:
id, user_id, comment
id, user_id, comment
id, user_id, comment
переведем это в значения
1, 1, privet
2, 1, poka
3, 1, kak dela
select comments.comment from comments where users_user_id = comments comments.user_id
как видешь user_id в комментариях не уникален, это связывающий столб с таблицей юзеров.

[codercat]

> user_id в user_counts уникальный, в комментариях конечно будет разным

user_counts хранит просто закэшированные количества разных действий юзера

[Therapyx]

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

[codercat]

Therapyx, не понял в чём проблема. Что, например, подсказывает?

[codercat]

Therapyx, популярный опыт когда кэшируют количества, например, вот так:

Таблица users
id | name | ... | posts_counts | comments_count | ...

И при создании новых комментариев создают комментарий и инкрементят users.comments_count. Я чисто для удобства решил отделить количества в отдельную таблицу и отдельную запись по ключу user_id. То есть инкремент теперь происходит вот так

increment user_counts.comments where user_id = {userId}. Не вижу проблем. Буду рад, если расскажешь что не так в таком подходе :)

[Therapyx]

codercat, сейчас уже точно не вникну в сложную логику чиловеков, только бара, но... погоди, зачем тебе каунт комментариев? На сколько это полезная информация? ) имею ввиду в плане логики, а не разве что показать сколько человек в целом сделал комментариев к примеру за хх времени(хотя и это такое себе...) :D

[codercat]

Therapyx, в смысле насколько полезная? Выводится в интерфейсе возле каждого профиля, людям интересно смотреть, оценивают так.

Например, в тостере в профилях тоже выводятся количества https://toster.ru/user/Therapyx (Вопросов, ответов). Сомневаюсь, что они каждый раз пересчитывают

Так и не понял где проблема в архитектуре тут.

[Therapyx]

codercat, я вот тогда тоже не понимал хД
Это я не верно понял таблицу. Тогда все ок))
Все таки профиль смотрят по сути не так часто, а вот каждый коммент, каждый лайк, каждое действие будет нагружать систему на дополнительный инсёрт в таблицу каунтеров. А сама по себе каунт функцию не комплексная, поэтому тут еще я бы на твоем месте задумался, что для тебя рациональнее то будет))