Создание сети подачи

Question

У меня есть таблица пользователей и таблица вопросов. В таблице вопросов будут содержаться записи, которые представляют «Вопросы», «Ответы» и «Комментарии» на вопросы или ответы. Я хотел бы создать панель для каждого пользователя, в которой можно увидеть действия, связанные с вопросами и ответами. Например, если пользователь A создает вопрос, а пользователь B отвечает ответом, а пользователь C отвечает комментарием к ответу пользователя B, то пользователи A и B могут видеть все эти действия в своих информационных панелях.

Это похоже на то, как работает домашняя страница Facebook, где, если я создаю видео, я могу видеть комментарии людей к моему видео.

Может ли кто-нибудь предложить простой способ смоделировать это в базе данных?

Answer 1

Я считаю, Facebook и др. и др. обрабатывайте это, имея отдельную базу данных общих «обновлений» записей, которые имеют краткое описание предпринятого действия. Всякий раз, когда кто-то выполняет действие на сайте, которое должно появиться на стене, запись также добавляется в базу данных обновлений.

Answer 2

Хорошо, вот что вы можете попробовать .. вы не можете вмешиваться в вопросы, ответы и их комментарии в одной таблице. Один вопрос может иметь много ответов, а разные ответы могут иметь разные комментарии. Хранение всех их в одной таблице будет довольно беспорядочным и не рекомендуется (по сравнению с правилами РСУБД). Сделайте три отдельных таблицы один для Вопросов, один для ответов и один для комментариев. Определите отношения между ними на основе первичных и внешних ключей. Поэтому в любой момент времени в таблице вопросов у вас есть все вопросы, заданные всеми пользователями. В таблице ответов будут указаны все ответы, соответствующие этому конкретному вопросу, и в таблице комментариев будут представлены комментарии к соответствующему ответу. Поддержание надлежащих опорных столбцов во всех таблицах позволяет легко управлять тем, что вы хотите. В любой момент времени вы можете увидеть все ответы, связанные с конкретным вопросом, присоединившись к таблице «Вопрос и ответ», также вы можете просмотреть все комментарии, сделанные по конкретному ответу, присоединившись к таблице «Ответ и комментарий».

Надеюсь, что это даст вы IDEA ..

Answer 3

Если вы собираетесь использовать один стол, вы можете попробовать что-то вроде этого.

TABLE { ID, ParentID, Идентификатор_пользователя, Тип, Текст, PostDtm }

Это дает вам базовую структуру дерева в одной таблице.

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

убедитесь, что у вас есть индексы на столбцах id как минимум.

Я до сих пор не уверен, сколько вам нужно. Такой сайт, как facebook, должен учитывать гораздо больше, чем оптимизацию на уровне таблиц. Для большинства сайтов реляционная модель учебника может быть запрошена более эффективно, чем эта модель. Каковы ваши целевые показатели эффективности?

Answer 4

enter code here @ Мое предположение заключается в том, чтобы укусить пулю, и если вы используете MySQL, то используйте отношения или переходите к другому типу базы данных, если хотите полностью уйти от таблиц с отношениями. Вы желаете «чистой» реализации атипичной модели RDB. Для RDB я предлагаю вам использовать четыре таблицы: пользователи, user_map, вопросы, ответы. Ответы являются категориальными (например, к Вопросу или Ответу), поэтому отслеживайте, какой тип он является, где единственными внешними ключами в любой таблице являются question.id и user.id.

Users: id, name 
User_map (can be used with Questions and/or Responses to join the data): u_id, q_id 
Questions: id, text_value 
Responses: id, q_id, text_value, category 

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