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

Question

Я делаю веб-приложение прямо сейчас и пытаюсь разобраться с дизайном базы данных.

У меня есть модель пользователя (имя пользователя (который является первичным ключом), пароль, адрес электронной почты, веб-сайт) У меня есть модель входа (id, title, content, comments, commentCount)

Пользователь может комментировать запись только один раз. Каков наилучший и наиболее эффективный способ сделать это?

В данный момент я думаю о другой таблице, которая имеет имя пользователя (из модели пользователя) и идентификатор записи (из модели ввода)

   **username    id**
    Sonic        4
    Sonic        5
    Knuckles     2
    Sonic        6
    Amy          15
    Sonic        20
    Knuckles     5
    Amy          4

Итак, чтобы составить список комментариев для записи 4, он ищет id = 4.

На примечании стороны: Вместо хранения commentCount, было бы лучше рассчитывать количество комментариев из базы данных каждый раз, когда это необходимо?

Answer 1

Вот моя рекомендация для вашей модели данных:

ПОЛЬЗОВАТЕЛИ таблица

• USER_ID (pk, int)
• USER_NAME
• ПАРОЛЬ
• EMAIL
• ВЕБСАЙТЫ

ENTRY Таблица

• ENTRY_ID (pk, int)
• ENTRY_TITLE
• СОДЕРЖАНИЕ

ENTRY_COMMENTS таблица

• ENTRY_ID (pk, fk)
• USER_ID (pk, fk)
• COMMENT

Эта настройка позволяет ЗАПИСИ иметь 0+ комментариев. При добавлении комментария первичный ключ, представляющий собой составной ключ ENTRY_ID и USER_ID, означает, что пара может существовать в таблице только один раз (IE: 1, 1 не позволит 1, 1 быть добавленным снова) .

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

Answer 2

Ваш дизайн в основном здоров. Ваша третья таблица должна иметь имя, похожее на UsersEntriesComments, с полями UserName, EntryID и Comment. В этой таблице у вас будет составной первичный ключ, состоящий из полей UserName и EntryID; это обеспечит соблюдение правила, согласно которому каждый пользователь может комментировать каждую запись только один раз. Таблица также будет иметь ограничения внешнего ключа, так что UserName должно быть в таблице Users, а EntryID должен быть в таблице Entries (в частности, поле ID).

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

Обновление : просто прочитайте ваш вопрос еще раз. Вам не нужны поля Comments или CommentsCount в вашей таблице записей. Комментарии должным образом будут храниться в таблице UsersEntriesComments, а количество запросов будет рассчитываться динамически в ваших запросах (избавляя вас от необходимости самостоятельно обновлять это значение).

Обновление 2 : Джеймс Блэк делает хороший вывод в пользу , а не , используя UserName в качестве первичного ключа и вместо этого добавляя искусственный первичный ключ в таблицу (UserID или некоторые другие ). Если вы используете UserName в качестве первичного ключа, разрешить пользователю изменять свое имя пользователя будет сложнее, так как вы должны также изменить имя пользователя во всех связанных таблицах.

Answer 3

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

Answer 4

Что именно вы подразумеваете под

entry model(id, title, content, **comments**, commentCount)

(выделено мое)? Поскольку, похоже, у вас есть несколько комментариев для каждой сущности, они должны храниться в отдельной таблице:

comments(id, entry_id, content, user_id)

entry_id и user_id - внешние ключи для соответствующих таблиц. Теперь вам просто нужно создать уникальный индекс (entry_id, user_id), чтобы пользователь мог добавить только один комментарий к сущности.

Кроме того, вы можете захотеть создать суррогатный (числовой, сгенерированный с помощью последовательности / идентификатора) первичный ключ для вашей таблицы пользователей вместо того, чтобы делать имя пользователя вашим PK.

Answer 5

Даже если это не так, вам может потребоваться идентификатор пользователя, который является первичным ключом, в противном случае будет трудно, если пользователю будет разрешено изменить свое имя пользователя, или если определенные люди будут знать, что вы не можете изменить свой имя пользователя.

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

Было бы полезно, если бы вы указали базу данных, кстати.

Answer 6

Похоже, вы хотите гарантировать, что набор комментариев является уникальным относительно username X post_id.Вы можете сделать это, используя уникальное ограничение или если ваша система баз данных не поддерживает это явно, с индексом, который делает то же самое.Вот некоторый SQL, выражающий это:

CREATE TABLE users (
    username VARCHAR(10) PRIMARY KEY,
    -- any other data ...
);

CREATE TABLE posts (
    post_id INTEGER PRIMARY KEY,
    -- any other data ...
);

CREATE TABLE comments (
    username VARCHAR(10) REFERENCES users(username),
    post_id INTEGER REFERENCES posts(post_id),
    -- any other data ...
    UNIQUE (username, post_id) -- Here's the important bit!
);