Подскажите по опыту какие данные могут находится в таблице users и может есть методичка как лучше организовать структуру. Использую PostgreSql поэтому выделил отдельную схему для users
Что будет на сайте:
1) Авторизация/регистрация (Логин, ник, пароль, имеил)
2) Ведение канала(По типу тг/пульса.)
3) Взаимодействие с другими пользователями, комментарии и лайки под постами
4)Может индивидуальные настройки (светлая/темная тема, приоритетные каналы лично для каждого)
Сделал отдельную таблицу fullname(Так как имена имеют много разных свойств)
При необходимости сделаю таблицу с адресом(Так как адреса всевозможные есть)
И вот как остальное можно было бы упаковать.
Может чтото ещё потребуется, возможно чтото упускаю
SQL
SQL,БД. Какие данные могут быть в таблице users?
это все может быть в таблице юзерс особенно если лень создавать новую таблицу для опшинсов, личной инфы, транзакций с баблом и т п
id, username, email,age, sex, date_create, date_update, avatar, status, phone, adress, balance, last_login, role_id
id, username, email,age, sex, date_create, date_update, avatar, status, phone, adress, balance, last_login, role_id
По опыту:
Блин, ответы все замыливают. Вот такие поля в Snowflake:
name
created_on
login_name
display_name
first_name
last_name
email
mins_to_unlock
days_to_expiry
comment
disabled
must_change_password
snowflake_lock
default_warehouse
default_namespace
default_role
default_secondary_roles
ext_authn_duo
ext_authn_uid
mins_to_bypass_mfa
owner
last_success_login
expires_at_time
locked_until_time
has_password
has_rsa_public_key

Блин, ответы все замыливают. Вот такие поля в Snowflake:
name
created_on
login_name
display_name
first_name
last_name
mins_to_unlock
days_to_expiry
comment
disabled
must_change_password
snowflake_lock
default_warehouse
default_namespace
default_role
default_secondary_roles
ext_authn_duo
ext_authn_uid
mins_to_bypass_mfa
owner
last_success_login
expires_at_time
locked_until_time
has_password
has_rsa_public_key
Таблицу сущности обычно называют в единственном числе: user, comment, address и так далее.
Выделите хотя бы такие сущности, которые находятся с пользователями в отношении «один ко многим» или «многие ко многим» и создайте для них отдельные таблицы.
Например, один пользователь пишет много комментариев, однако каждый комментарий пишется лишь одним пользователем. Это отношение «один ко многим».
Оно обычно реализуется путем добавления ссылки (внешнего ключа) в таблицу сущности, которой в этом отношении «много». Например, таблица user содержит первичный ключ id, а таблица comment содержит ссылку на автора — внешний ключ user_id или author_id.
Например, Миша (id=1) написал два комментария — id=53 и id=55.
А Вася (id=2) написал один комментарий — id=54.
В таблице comment эти комментарии будут записаны так:
Оно реализуется путем создания промежуточной таблицы с парами ссылок — туда и сюда.
Например, есть два пользователя: Петя (id=1) и Миша (id=2).
Петя подписан на группу «МХК» (id=1) и «Котизм» (id=2).
Миша подписан на «МХК» (id=1) и «Лепрозорий» (id=3).
Пусть Петя и Миша сидят в таблице user, а группы — в таблице group.
Промежуточную таблицу назовем user_group, и в ней будут два внешних ключа:
Выделите хотя бы такие сущности, которые находятся с пользователями в отношении «один ко многим» или «многие ко многим» и создайте для них отдельные таблицы.
Например, один пользователь пишет много комментариев, однако каждый комментарий пишется лишь одним пользователем. Это отношение «один ко многим».
Оно обычно реализуется путем добавления ссылки (внешнего ключа) в таблицу сущности, которой в этом отношении «много». Например, таблица user содержит первичный ключ id, а таблица comment содержит ссылку на автора — внешний ключ user_id или author_id.
Например, Миша (id=1) написал два комментария — id=53 и id=55.
А Вася (id=2) написал один комментарий — id=54.
В таблице comment эти комментарии будут записаны так:
id | author_id | text
53 | 1 | Ответ на главный вопрос жизни — 42.
54 | 2 | Такой дурацкий ответ на такой великий вопрос!
55 | 1 | Да? И что же это за вопрос?
Другой пример: каждый пользователь подписан на много каналов, и на каждый канал подписано много пользователей. Это отношение «многие ко многим».Оно реализуется путем создания промежуточной таблицы с парами ссылок — туда и сюда.
Например, есть два пользователя: Петя (id=1) и Миша (id=2).
Петя подписан на группу «МХК» (id=1) и «Котизм» (id=2).
Миша подписан на «МХК» (id=1) и «Лепрозорий» (id=3).
Пусть Петя и Миша сидят в таблице user, а группы — в таблице group.
Промежуточную таблицу назовем user_group, и в ней будут два внешних ключа:
user_id | group_id
1 | 1 // Петя и МХК
1 | 2 // Петя и Котизм
2 | 1 // Миша и МХК
2 | 3 // Миша и Лепрозорий
Если вам нужны подробности, то стоит поискать матчасть по теме «Нормальные формы базы данных». Например, на Хабре: https://habr.com/ru/post/254773/Похожие вопросы
- 5.Операторы SQL для выборки данных из таблицы в Oracle?
- SQL Запрос. Дублируются данные
- Блин что то не могу найти способ произвести эффективную выборку данных из таблицы БД?
- SQL. Выводятся не все данные. 4 задача.
- Вопрос по SQL - уникальное поле ID для трёх таблиц (нельзя вставить значения в одну, если оно есть в другой таблице).
- Приведите примеры удачного использования драйверов БД во фреймворках, более высокоуровневых, чем SQL.
- SQL. Есть таблица а и b как мне поставить ограничение на поле таблицы b, на основании поля таблицы a? пример в описании
- Нестандартное извлечение данных из БД
- Как вставить данные из одной БД в другую?
- Вывод данных из бд в dataview?