Как вы структурируете базу данных, которая позволяет голосовать так же, как это делает stackoverflow?

Question

Я новичок в создании баз данных и веб-разработок, но я стараюсь изо всех сил учиться на этом пути, создавая свой собственный динамический веб-сайт. Я делаю это шаг за шагом и в настоящее время разрабатываю модель данных на бумаге. Мне интересно, как создать структуру базы данных для веб-сайта, которая позволяет голосовать, как это делает stackoverflow? Если есть таблица, содержащая список вопросов, каждый вопрос, который создается пользователем, добавляется в эту таблицу. Не может быть просто поле на этой таблице, которое подсчитывает голоса, потому что это позволит одному человеку иметь неограниченные голоса? Таким образом, должен быть ключ, который соединяется с другой таблицей, которая подсчитывает голоса и отслеживает пользователей, чтобы они не могли голосовать дважды, правильно? Если это правда, это та часть, где я запутался. Каждый ответ также может быть проголосован. То есть это означает, что когда пользователь отправляет ответ, помимо добавления этого ответа, вероятно, к отдельной таблице для ответов на заданный вопрос, модель также должна генерировать новую таблицу для каждого ответа динамически во время выполнения, чтобы отслеживать все эти голоса?

Обратите внимание, что я не спрашиваю конкретно о том, как это делает stackoverflow, но как работает концепция того, что работает пользователь.

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

Есть ли лучший способ сделать это, чтобы кто-то мог объяснить в мирянах? Нет необходимости в конкретном коде ... Возможно, я смогу понять это позже, когда придет время. Сейчас я просто теоретизирую и строю бумажную модель, чтобы работать позже.

EDIT: О, я вижу. Я думаю, что в Excel-таблицах, когда я думаю о таблицах базы данных, так исправьте меня, если мое понимание ошибочно. Таким образом, каждое голосование по всему сайту находится на одной таблице (перечисленной вертикально на электронной таблице), каждая из которых имеет строку данных (по горизонтали), которая связывает голосование с разными владельцами (пользователь и вопрос ИЛИ ответ)? Это верно? Я отвечаю на вопрос «ИЛИ», потому что я не понимаю сценарий, когда было бы разумно иметь их как атрибут «голос» (не уверен, что это правильная терминология) вместо того, чтобы создавать две отдельные голоса для ответа и вопрос, который проголосовали. В основном, как я вижу, каждая строка представляет собой голосование, и есть 3 поля, 1. Значение (+1 или -1), 2. От кого (имя пользователя), 3. К чему (вопрос или ответ).

Answer 1

Вы должны посмотреть на все элементы. В основном у вас есть

Questions 
Users 
Answers 
Votes 

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

tblQuestions 
    questid 
    question 
    userid 

затем

tblAnswer 
    Answer 
    answerid 
    userid 
    questid 
    accepted (to flag as accepted answer) 

и, наконец,

tblVote 
    vote (up or down) 
    questid 
    answerid 
    userid 

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

Answer 2

CREATE TABLE "QuestionVote" (
    "Question" INT NOT NULL, -- To identify the question being voted on 
    "User" INT NOT NULL, -- To identify the user who is casting their vote 
    "Vote" SMALLINT NOT NULL CHECK ("Vote" = 1 OR "Vote" = -1), 
    PRIMARY KEY ("Question", "User"), 
    CONSTRAINT "Constr_QuestionVote_Question" 
     FOREIGN KEY "QuestionVote_Question" ("Question") 
     REFERENCES "Question" ("ID"), 
    CONSTRAINT "Constr_QuestionVote_User" 
     FOREIGN KEY "QuestionVote_User" ("User") 
     REFERENCES "User" ("ID") 
) 

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

Answer 3

Использование подхода NOSQL к документу. (CouchDB)

База данных: Stacklike

документов в базе данных Stacklike:

{ 
    "type": "question", 
    "user": "<userid>" 
    ... 
} 

{ 
    "type": "answer", 
    "user": "<userid>", 
    "question": "<questionid>" 
    ... 
} 

{ 
    "type": "vote", 
    "user": "<userid>", 
    "question": "<questionid>", 
    "weight": "<weight>" 
    ... 
} 

{ 
    "type": "user", 
    ... 
} 

Просмотров:

к списку голосов, отсортированных по Вопрос

map(doc){ 
    if (doc.type === 'vote'){ 
    emit(doc.questionid, doc) 
} 

, чтобы увидеть Vote Графы и совокупными (статистика)

map(doc){ 
    if (doc.type === 'vote'){ 
    emit(doc.questionid, doc.weight) 
} 
reduce(keys,values, rereduce){ 
    _stats 
}