Приветствую!

Господа профессионалы. Помоги пожалуйста дельным советом, как спроектировать базу данных для социальной сети, где встречаются ученики и учителя в одной профессиональной отрасли.

Я сделал несколько связанных между собой табличек, на сколько оптимальна такая структура и как можно было бы её улучшить?

Таблица users:

id
displayName
birthday
gender
professional_id
deleted
blocked
block_reason

Таблица users_uids:

uid
user_id
deleted
blocked
block_reason

Таблица persons

id
displayName
personType (professional or center)
deleted
blocked
block_reason

Таблица professionals:

id
personID
gender
birthday

Таблица centers

id
personID
registrationDate

Таблица photos

id
personID
link
deleted

Таблица students

id
personID
professional_id
course_id
progress

Идея в том, что есть мастер таблица persons, в которой хранятся и конкретные профессионалы и учебные центры.
Профессионалы могут обучать других профессионалов, а учебные центры могут также заниматься образовательной деятельностью и нанимать на работу людей из таблицы professionals. Для примера есть таблийа photos. Владельцем фото может быть как прлфессионал, так и учебный центр.

Таблица users нужна, чтобы войти в систему.
А таблица users_uids хранит uid для каждого пользователя, чтобы он мог зайти или через соц сеть или через email (проверка происходит на стороне firebase и на клиенте и на сервере).

Интуитивно мне кажется, что таблица users в этой структуре лишняя и можно ограничиться таблицей professionals, а users_uids можно переименовать в professionals_uids.

Смущает, что поля gender и birthday дублируются в users и professionals и при определенных условиях могут противоречить друг другу.

С другой стороны, со временем мне захочется добавить администраторов для учебных центров, которые по сути своей могут не являться профессионалами обучения, но являются простыми пользователями системы.

Как оптимальнее организовать базу?

Модератор: Тема перенесена из форума "PostgreSQL".

fkthat, если у Вас больше идей нет, предлагаю Вам далее не участвовать в обсуждении этой темы.

Alex_Ustinov,

что Вы имеете ввиду?

Никанор Кузьмич,

почему, же оставайтесь, участвуйте.
Но если Вам не сложно высказывайтесь по существу и конкретно.

1. Что конкретно плохого в такой структуре?
2. Что конкретно почитать и что в вашем понимании является нормальными формами?

Для удобства восприятия вкладываю схему связей таблиц.

Ткните уже, наконец, в конкретное место и подскажите как исправить.
В этом же и заключается мой вопрос... Избыточные, ненормализованные данные, я пока обнаружил в таблицах users и professoonals, и именно поэтому я и задался вопросом, что мне кажется, это можно было бы оптимизировать. Но как, не очень понимаю, ведь пользователем системы может быть любой человек, а вот участником таблицы professionals, не каждый.

Я потратил на эту схему 3 минуты своего времени. Мне правда не жалко её выкинуть и сделать новую.
Но вы конкретнее можете сказать как она должна выглядеть по-новому? Уверен, что вы потратите на эту задачу времени не больше.

В конце концов тема о проектировании базы...

Читайте внимательнее тогда, дублирую:
ElfixИдея в том, что есть мастер таблица persons, в которой хранятся и конкретные профессионалы и учебные центры.
Профессионалы могут обучать других профессионалов, а учебные центры могут также заниматься образовательной деятельностью и нанимать на работу людей из таблицы professionals. Для примера есть таблийа photos. Владельцем фото может быть как прлфессионал, так и учебный центр.

Таблица users нужна, чтобы войти в систему.
А таблица users_uids хранит uid для каждого пользователя, чтобы он мог зайти или через соц сеть или через email (проверка происходит на стороне firebase и на клиенте и на сервере).


Когда Вы писали
Никанор КузьмичВ вашем случае из 8 присутствующих таблиц 6 нужно слить в одну, и добавить пару-тройку таблиц справочников.


Что вы имели ввиду? Можно пример?

Dimitry Sibiryakov, нет, сейчас пользователь может заходить любым удобным для себя способом: используя email или facebook, или google, или все одновременно.

17-77, большое спасибо за содержательный и конкретный ответ.
Также большое спасибо за Ваше видение структуры.

Но, немного не так.

Таблица persons - это по сути общая таблица и для professionals и для centers.
По сути ведь, образовательные услуги может оказывать как конкретное физическое лицо, так и целая организация.
У физического лица есть набор специфичных полей в таблице professionals (дата рождения, пол и т. п.), а у организации (centers) есть набор своих полей (дата регистрации, графики работы, руководитель, администратор). При этом организация может включать в себя много физических лиц, выполняющих образовательные услуги, а физическое лицо всегда само по себе.

От лица профессионала залогиниться можно, а вот от лица учебного центра нет - ведь в учебном центре всегда есть конкретный профессионал, который за ней стоит, а значит этот профессионал может залогиниться как профессионал и далее уже выполнять все необходимые функции по вверенному ему учебному центру.

Например, если в будущем пользователь захочет увидеть сквозной список тех кто оказывает образовательные услуги, тогда мы ему покажем записи таблицы persons, а по свойству type мы поймем где взять дополнительную расширенную информацию о том, кто будет обучать конкретно - из таблицы centers или из таблицы professionals.

В таблицах есть поля deleted - это если какой-то профессионал удалился, но для истории хранится в базе - на досках объявлений, в сообщениях, в лайках, отзывах и т. п. Удалять такую информацию по моему мнению наверное не нужно, и это поле в будущем поможет настраивать PARTITIONS, чтобы немного разгрузить базу, если в ней наберется сколько угодно много записей.

Мне интуитивно кажется, что можно обойтись без таблицы users, сразу же используя таблицу professionals и к ней уже привязывать таблицу с возможностями авторизации. Но, смущает то, что тогда в ней окажутся люди, которые являются администраторами-секретарями учебных центров, а профессионалами не являются и никогда не являлись. А значит не должны выводиться в списках людей, предлагающих свои услуги...

Dimitry Sibiryakov, по моей изначальной задумке есть таблица users, в ней есть поле blocked.
Есть таблица users_uids, в которой хранятся uids из базы firebase.

На клиенте firebase авторизует клиента и получает uids и токен, сервер этот токен проверяет и по нему находит uids.
А по uids уже понимает какие поля надо достать из таблицы users, чтобы пользователь узнал себя. Таким образом, я не храню ни логины, ни пароли нигде, доверяю вопрос идентификации стороннему сервису firebase.

Если поставить атрибут blocked в таблице users, то независимо от того каким способом авторизовался пользователь он в любом случае будет заблокирован сервером и зайти ему уже не удастся.

17-77,

немного переделал схему. Получилось вот так.

В таком случае если уж Вы решили создать клон LinkedIn - начните с изучения оригинала:
http://www.databaseanswers.org/data_models/linked_in/index.htm
Спасибо, вот это действительно интересная информация. Изучаю.