Всем привет!
Не могу никак додумать как лучше хранить пользователей на сайте.
У меня есть таблица user и profile. В них попадают все зарегистрированные пользователи. Обьязатедьными полями являются пароль и email.
Дальше у меня будет модуль организаций с хранением информации об организациях. У организаций может быть несколько ролей: сотрудники: директор, Руководитель, тренер, хореограф.... Личности организации: танцоры, певцы, спортсмены....
Далее есть модуль мероприятий. У мероприятия могут быть:
Оргкомитет: организатор, ведущий, счётчик, волонтёр, охранник
У каждого мероприятия есть регистрация и в нем:
Наставники: преподаватель, хореограф, тренер... (из модуля организации - сотрудники)
Участники: танцор, спортсмен, певец...(из модуля организации - личности)
У меня получается полная связь между таблицами. И теперь я думаю как спроектировать базу. Ведь профиль у всех одинаковый, но роли могут быть разные.
Кроме как повесть это все на Таблицы: user и profile. Подумал сделать под каждого отдельные Таблицы, но это не разумно. Нужно будет делать синхронизацию данных и этих данных будет слишком много. Что увеличит БД.
Авторизация пользователя по таблице user. Основные данные из profile (фамилия, имя, дата рождения...)
У меня собственно два вопроса:
1. Правильно ли все повесить на две таблицы? Думаю, да. Тогда Второй вопрос.
2. Пользователи могут добавить не все поля, а, например, только нужные для определенного модуля фамилию и имя. Но как мне быть с авторизацией таких пользователей? Ведь авторизация по email. Это обязательное поле Таблицы user. К profile будет привязываться ещё и статистика других модулей, рейтинги, достижения... Все эти данные будут привязаны к user и профилю. Но если в одном месте не заполняют email, то у пользователя появляется возможность создать новый аккаунт и вести новую статистику. Потом он заметит, что вдруг у него два аккаунта и придётся их совмещать. Или же вдруг объявился владелец созданного аккаунта. Например, ребёнок вырос и ему нужно получить доступ. С этим пунктом вопроса я затормозил. И не знаю как пойти дальше и реализовать. Подскажите! Буду очень благодарен!
VMesser, хочу профиль сделать отдельным. Там будет много разной информации. А user будет хранить именно данные аккаунта для авторизации. То есть вы считаете что лучше не плодить множество таблиц под каждую роль, а сделать одну две?
этого можно начать побаиваться если пользователей перевалит за миллионы. Ну или если это реализация в наручных часах, где маловато ресурсов)
А так - один из вариантов:
- учетные записи (не совсем юзер)
- контрагенты (люди-организации-семьи)
- контактные данные (разных типов)
- связи (разных типов между контрагентами - муж-жена-работник итп)
- уровней доступа (ролей, профилей)
- статистики и пр
это несколько избыточная структура, но она позволит "обработать" ситуации, когда человек работает в нескольких организациях сразу, пару раз менял семью, члены которой еще оказывается сами работники других организаций в базе.
d-stream, Ахаз. Хорошо. С этим я справлюсь. Но как мне тогда выводить общий профиль? Делать друзей, рейтинг, Сообщения? Сортировать кто онлайн кто нет. Проводиизводить общий поиск
Максим, а в чем проблема?
контрагент = профиль, может иметь или не иметь:
- учетную запись
- контакты (сайты, учетки в соцсетях и т.п.)
- связи разных типов на таких же других контрагентов
ну и прочая мишура так или иначе пляшущая вокруг уникального id контрагента
d-stream, просто не очень хорошо знаю именно правильное построение баз. Можете для тупых на пальцах объяснить?) Просто давно с этим вопросом хожу и никак не могу разобраться как делать... могу даже заплатить за пояснения)
Исходя из ваших слов я понял следующее:
Делать одну общую таблицу профиль, или контрагенты, или люди.
Далее, если нужно авторизовываться на сервере - делаем для него таблицу учетных данных user.
В модуле регистрация создаём Таблицы участников и наставников.
В модуле мероприятия создаём таблицу оргкомитет: организатор, ведущий...
В этих таблицах есть поле owner_id с которым связываем профиль (контрагент.), но при этом все поля: ФИО телефон у них свои.
Чтобы эти данные были везде одинаковые - делаем синхронизацию таблиц по полю owner_id. При редактировании ищем по этому id во всех таблицах и обновляем информацию. Этой синхронизацией будет заниматься модуль медиатор.
Правильно я мыслю?
Или же создавать один профиль(контрагент) и ссылаться на него во всех этих модулях и подзавить на независимость модулей))
d-stream, про нормализацию читал, но сложнее)
Простите, но все равно не совсем понял)) Во первых у меня нет контрагентов. Давайте их называть будем люди.
Получается такая структура:
User:
- id
- email
-password
People
- user_id
- last_name
- first_name
- middle_name
People Contact
- people_id
- email
- phone
Далее пошли таблицы модулей:
Модуль организации:
Persone
- id
- user_id
- nickname
....
Employee
- id
- user_id
- должность
...
Все контакты подгружаются у сотрудников и личностей по связям с таблицей People Contact, а аватар и фамилия по связи с People Contact
Максим, как идентифицировать конкретный контакт?
сотрудник - это человек, имеющий отношение (связь) с организациями и роль (должность) в каждой конкретной организации
ну и так далее
d-stream, через связь employee.user_id => people.user_id это получили профиль. Если нужно контакт, то через таблицу people к people contact. Или опять не правильно мыслю?))
d-stream, смотрите в общем весь вопрос описал получше....
Всем привет!
Насмотревшись уроки Елисеева Дмитрия, а конкретно по независимым модулям Стал задумываться как все построить?
Раньше задавал подобный вопрос, но так для себя и не понял. Постараюсь развёрнуто задать его снова.
Изначально делил ВСЕ на модули
Модуль USER
Отвечает за авторизацию и хранение основных настроек: авторизация, восстановление пароля, регистрация...
Таблица user
Таблица profile
Модуль DISCIPLINE
Отвечает за хранение данных дисциплин
Модуль ORGANIZATION
Раздел организаций (школы танцев, коллективы, музыкальные школы...) отвечает за хранение информации об организациях, статистика организаций, Контакты, отзывы.
У людей организации может быть несколько ролей: директор, руководитель, тренер, хореограф.... танцоры, певец, спортсмен....
Модуль EVENT
Модуль мероприятий отвечает за работу с мероприятиями и календаря
Мероприятия могут организовывать организаторы и организации.
У мероприятия могут быть люди:
организатор, ведущий, счётчик, волонтёр, охранник
Таблица оргкомитет.
Модуль REGISTRATION
Отвечает за регистрацию участников на мероприятие, ведёт статистику, рейтинг, приём оплаты, подсчёт финансов, выгрузка различных отчетов и списков.
У меня получается полная связь между таблицами и модулями. И теперь я думаю как спроектировать базу. Ведь профиль у всех одинаковый, но роли могут быть разные и отличаться несколько полей. При этом мне необходимо искать по всем людям, выводить их друзей, показывать кто онлайн, кто оффлайн, выводить общий рейтинг.
Немного подумав понял, что модулей слишком много. Много относится к одному модулю организации. Поэтому разумнее обьединить часть модулей в модуль организации.
Вот что получается, если объединить по организации:
МОДУЛЬ USER
user
- email
- password
- hash
- vizit_at
people
- id
- user_id
- last_name
- first_name
- middle_name
- birthday
- gender
friend
- from_id
- to_id
- status
message
- from_id
- to_id
- text
МОДУЛЬ ДИСЦИПЛИН
discipline (дисциплины)
- id
- name
МОДУЛЬ ОРГАНИЗАЦИИ
organization
- id
- name
- type (тип организации: Школа танцев, музыкальная школа, спортивная школа....)
- event_count
- people_count
org_rewiew (отзывы)
- id
- people_id (может быть Null)
- text
- active
org_people люди организации)
- org_id
- people_id
- role (директор, танцор, руководитель, тренер, певец спортсмен...)
org_people_director
- id
- people_id
- position (должность)
org_people_dancer
- id
- people_id
- nickname (ник)
- org_people_dancer_mentor (наставники танцора)
- dancer_id (id people)
- mentor_id (id people)
- role (тренер, руководитель, педагог)
/// и так по всем ролям, где нужны дополнительные поля
organization_event (мероприятия организации)
- id
- org_id (Организация)
- name
- date_from
- date_to
- type (фестиваль, мастер-класс, лагерь...)
org_evt_discipline (дисциплины для регистрации)
- event_id
- discipline_id
- active
org_evt_req_participant (участники, связь заявки и людей)
участниками могут быть все люди без привязки к организации
- request_id
- people_id
- role (танцор, певец, спортсмен)
org_evt_req_mentor (наставники, связь заявки и людей)
Наставниками могут быть все люди
- request_id
- people_id
- role (директор, руководитель, тренер, педагог)
Пример подобного проекта вот: https://godance.tv
Но там нет функционала регистрации.
d-stream, немного понял.
Школы танцев и школа рисования будет одна и та же таблица. Если данные совсем другие, то придется сделать отдельную таблицу со связью. В связанной таблице указать эти данные. например. ortaganization.art (организация школы рисования и в art таблице дополнительные поля.) Думаю так...
Простой
Средний
