Есть ли необходимость в unsigned integer id для one to one отношений?
Есть таблица юзеров (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? Возможно, он помогает каким-то внутренним операциям движка бд происходить быстрее или можно убирать?
Это обычная практика при проэктировании таблиц. Есть primary key и есть foreign key. В данном случае user_id в таблице. Первичный ключ должен быть всегда "уникален". Если не айди, то что тогда возмешь ты как уникальность всех строк? В противном случае придется брать comments или Likes или votes или notifications или же комбинации из них. Но где гарантии, что не попадется 2 одинаковые комбинации к примеру из коммента и нотификации.? Да и ставить ключ с тем же комментом ххх символов? ))
Надеюсь разьяснил внятно )
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, что-то мне подказывает, что проектировка в твоем случае совсем через одно место)) читал про нормализацию баз данных?
я конечно не знаю каковы твои познания, поэтому трудно так просто отвечать. Может тут какая-то специфичная ситуация или проблема, а может ты просто учишься))
Therapyx, популярный опыт когда кэшируют количества, например, вот так:
Таблица users
id | name | ... | posts_counts | comments_count | ...
И при создании новых комментариев создают комментарий и инкрементят users.comments_count. Я чисто для удобства решил отделить количества в отдельную таблицу и отдельную запись по ключу user_id. То есть инкремент теперь происходит вот так
increment user_counts.comments where user_id = {userId}. Не вижу проблем. Буду рад, если расскажешь что не так в таком подходе :)
codercat, сейчас уже точно не вникну в сложную логику чиловеков, только бара, но... погоди, зачем тебе каунт комментариев? На сколько это полезная информация? ) имею ввиду в плане логики, а не разве что показать сколько человек в целом сделал комментариев к примеру за хх времени(хотя и это такое себе...) :D
Therapyx, в смысле насколько полезная? Выводится в интерфейсе возле каждого профиля, людям интересно смотреть, оценивают так.
Например, в тостере в профилях тоже выводятся количества https://toster.ru/user/Therapyx (Вопросов, ответов). Сомневаюсь, что они каждый раз пересчитывают
codercat, я вот тогда тоже не понимал хД
Это я не верно понял таблицу. Тогда все ок))
Все таки профиль смотрят по сути не так часто, а вот каждый коммент, каждый лайк, каждое действие будет нагружать систему на дополнительный инсёрт в таблицу каунтеров. А сама по себе каунт функцию не комплексная, поэтому тут еще я бы на твоем месте задумался, что для тебя рациональнее то будет))
Простой