У меня есть сайт, в котором пользователи создают сообщения в фиде и могут иметь много каналов. В их профиле будет отображаться фид по умолчанию по своему выбору.Как вы решаете парадокс реляционной базы данных?
3 таблицы в этом парадоксе - это «учетные записи», «профили» и «фиды». Запись в профилях содержит дополнительную информацию о пользователе. Это находится в отдельной таблице, потому что она может быть изменена чаще, и многие запросы используют таблицу учетных записей, не требуя этой информации.
Поле в счетах (профилях) должно ссылаться на профиль. Я сделал это, вместо учетных записей профилей, потому что в противном случае учетная запись могла бы существовать без профиля. Профиль, существующий без учетной записи, будет являться результатом деактивированной учетной записи (при условии, что пользователь явно решил не удалять свой профиль с сайта).
Поле в профилях (default_feed) должно ссылаться на канал. Это может часто изменяться и не требуется большинству запросов, поэтому это кажется разумным местом для этих данных.
Поле в источниках должно ссылаться на учетную запись; у всех фидов есть создатель.
Возможно, вы уже можете увидеть мою проблему, но я уточню: Я не могу сделать учетную запись без создания профиля, который я не могу сделать, не создавая фид, который я не могу сделать без учета учетной записи и т. д.
Должен ли я отказаться от функциональности профилей для деактивированных учетных записей (что не было бы огромной сделкой, но я хотел бы знать, есть ли другой способ), или есть разумный трюк, который позволит мне решить парадоксальный характер этих отношений?
EDIT: Я понял, что могу просто установить поле default_feed, чтобы оно было пустым, а приложение обработало этот специальный случай (что никогда не должно происходить, так как фид создается с учетной записью) с помощью «у этого пользователя нет сообщения по умолчанию». Я все же хотел бы узнать, не пропустил ли я более творческое решение.
Спустя минуту после моего редактирования. Тем не менее, это идеальное решение. –