Проектирование отношений базы данных - связь двух таблиц дважды в разных таблицах

Question

У меня есть следующие таблицы:

Post
Id int

User
Id int

Тогда у меня есть стол

Favorite
PostId int
UserId int

и стол

Vote
PostId int
UserId int
IsUpVote bit
IsDownVote bit
LastActivity datetime2

проблема в том, что если бы я объединил и Избранное, и Голосование в одну таблицу, я бы получил что-то вроде

UserPost
PostId int
UserId int
IsFavorited bit
IsUpVoted bit
IsDownVoted bit
LastActivity datetime2

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

Таким образом, вопрос в том, как неправильно иметь в этом случае две таблицы, относящиеся к таблицам A и B (Post,User), которые в этом случае индексируются одним и тем же первичным ключом (PostId,UserId), но предназначены для разных целей?

Answer 1

Фавориты и Голоса, кажется, две разные вещи, поэтому ИМХО вам будет лучше хранить их как отдельные таблицы. Как вы упомянули, вы потеряли бы функциональность, если бы вы объединили их, и я не вижу какой-либо явной выгоды от их объединения. Придерживайтесь того, что у вас есть, если вы не можете предоставить удивительное обоснование слияния.

Answer 2

Ничего плохого.

Я не говорю, что предоставленный DDL показывает правильно нормализованные таблицы, но они несколько нормализованы. Как вы определили, две таблицы имеют разные цели, они имеют разное значение, поэтому технически (теоретически, академически и на практике [код]) они верны.

• «относится к одним и тем же родителям» не является критерием (есть много случаев, когда существует множество таблиц, относящихся к одним и тем же родителям и которые являются правильными)
• поэтому такие таблицы будут "иметь одинаковые PK и FK", так что это тоже не критерий.

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

Голосование и Фаворит - это две разные вещи, сущности, записи о предпринятых действиях. Две таблицы верны.

Различие: Истинная причина, по которой IsDownVoted больше нельзя сравнивать, заключается в том, что он не относится к избранным. Вы использовали индикатор (бит), чтобы идентифицировать это (хотя и плохо назвали); который действительно заменяет пустой столбец. Нули не годятся для производительности, и хорошо, что у вас есть индикаторы, позволяющие идентифицировать отсутствие данных, и, следовательно, вы избегаете пустых значений, но это отдельное от взлома нормализованного проекта путем их простоты.

Объединенная таблица будет работать медленнее при любом доступе. Когда вы выбираете из него голоса, вы должны исключить избранное и наоборот, но он будет выполнять ввод-вывод для обоих, потому что они расположены вместе (PostId, UserId). SO сервер всегда читает в два раза больше строк, используя вдвое больше кеша; и т.д. Затем вы «добавите скорость» путем добавления индекса для (PostId, UserId, IsFavourited), что сделает его еще более медленным для вставок и удалений (в то время как «ускорение» выбирает). Мессы составляются, гарантировано; Лучше всего не иметь никакого беспорядка во-первых.

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

Вы принимаете ответы слишком быстро.

Answer 3

Хотя я не буду говорить, что вам следует делать с таблицами, если вы используете int вместо битов и используете значения, такие как 0 1 и -1, для вычислений / сравнений, таким образом вы можете вычислить нужные значения в относительно простойway.

Говоря о реляционных базах данных, вы почти всегда должны стремиться к 3-й нормальной форме относительно ваших таблиц - попробуйте взглянуть на http://en.wikipedia.org/wiki/Database_normalization

Cheers!