Дизайн базы данных

Question

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

Каждый из этих владельцев учетных записей также имеет несколько сообщений от других пользователей и другого содержимого социальных сетей, таких как блоги, ... Мой вопрос заключается в том, связывать ли эти сообщения, блоги, занятия, ... с account_id или person_id ?

=============================================== ================================== UPDATE: Хорошо, я думаю, я не очень креативно разработал свой вопрос. В простом приложении я мог бы создать таблицу только для пользователей и сохранить всю информацию для входа в систему, а также информацию о пользователе, такую ​​как first_name, ..., и связать сообщения и другие данные с user_id.

Но, поскольку я хочу, чтобы пользователи могли создавать множество записей о персонах (не только для себя, но и для других, которые могут включать информацию о пользователях, которые еще не создали свои учетные записи), я подумываю разделить информацию для входа на Таблица ACCOUNTS (или назовите ее таблицей USERS) и информация профиля в таблицу PEOPLE. Каждый владелец аккаунта будет иметь только одну личную запись (свою, и это информация, которая идентифицирует их с миром, так как информация для входа предназначена только для проверки подлинности системы). Допустим, вы создали учетную запись, а также свою личную запись, видели человека Билла Гейтса и хотели отправить ему сообщение, у нас есть два сценария: (1) Запись о личности Билла Гейтса не претендует ни на одного владельца аккаунта как на свое лицо
(2) У записи лица Билла Гейтса есть связанный владелец счета В сценарии (1) система даже не позволит вам отправить сообщение, так как нет владельца учетной записи, который мог бы проверить сообщения, и в сценарии (2) я должен сохранить идентификатор person_id BillGates в receivers_id таблицы MESSAGES или BillGates.account. .Я бы ? То же самое относится ко всем другим типам контента, таким как блоги, фотографии, ...

Посмотрим, смогу ли я составить таблицу связей:

ACCOUNTS
id
login
password
person_id (account holders personal record)

---

PEOPLE
id
first_name
....
creater_id (current_account().person.id or just the current_account().id ?)
updater_id (current_account().person.id or just the current_account().id ?)

---

MESSAGES
sender_id (current_account().person.id or just the current_account().id ?)
receiver_id (person.id or person.account.id ?)
subject
body

---

BLOGS
id
title
body
author_id (current_account().person.id or just the current_account().id ?)

Надеюсь, я высказал свое мнение. Если нет, дайте мне знать, я постараюсь придумать другие примеры.

Answer 1

Я бы сказал, что это зависит от цели. Если вы хотите указать владельца сообщения, сообщения в блоге и т. Д., Я бы использовал account_id, поскольку для создания такой записи необходимо подтвердить подлинность пользователя.

Если вы хотите отметить, что сообщение ссылается на других людей, я бы использовал people_id

Answer 2

Вы уже говорите это сами. «Каждый из этих владельцев также имеет ...»

Владельцы аккаунтов имеют сообщения, блоги и так далее. Таким образом, они должны иметь учетную запись. Если вы хотите, чтобы у людей без аккаунтов были те, вы должны использовать person_id

Answer 3

Если всегда есть ровно один человек, связанный с одним владельцем учетной записи, тогда они в некотором смысле описывают одно и то же, и поэтому не имеет значения, куда вы помещаете блог, сообщения и т. Д. В этом случае я бы пошел с что когда-либо является наиболее интуитивным, поскольку это не имеет структурного значения, что, вероятно, означало бы поместить его в таблицу Person.

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

Редактировать: очень важно установить индивидуальное уникальное ограничение для внешнего ключа (независимо от того, в какую таблицу вы его положите). В противном случае ваша однозначная ассоциация может легко стать взаимно однозначной, если неосторожный пользователь введет, например, новую строку account_holder и присвоит ему тот же «ownerID», что и предыдущий account_holder. В этом случае ownerID является внешним ключом из таблицы Person и нуждается в уникальном ограничении.

Редактировать # 2: Просматривая ваше разъяснение вопроса, я не вижу причин, чтобы не иметь ни одной таблицы «ПОЛЬЗОВАТЕЛИ». Просто имейте логический атрибут «acitivated», который означает, что у этого человека есть активная учетная запись с действительными учетными данными для входа. Когда человек создает учетную запись, но не вводит какую-либо личную информацию, «активированный» будет иметь значение «истина», но поля личной информации останутся пустыми. И если этот пользователь создает профили других людей, в ПОЛЬЗОВАТЕЛЯХ будут вставлены новые строки, содержащие всю их личную информацию, но поля «имя пользователя» и «пароль» будут НЕДЕЙСТВИТЕЛЬНЫМИ, а значение «активировано» будет ложным. Разве это не было бы самым бесшовным и простым? Пользователь и account_holder - это одно и то же (именно поэтому вы получаете однозначную связь), так почему бы не оставить все это в одной таблице?