0

У меня есть приложение, которое связывает пользователей с определенными группами в стиле Facebook.Каков наиболее эффективный способ указать разрешения пользователя в базе данных?

Например:

Пользователь A связан с группой 1 и группой 2

пользователя B связан с группой 2 и 4 группы

Пользователи могут создавать сообщения (небольшие суммы текста) для каждой группы, к которой они принадлежат.

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

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

В моем приложении, у меня есть эти три модели (псевдокод):

class User(): 
    user_name 
    first_name 
    last_name 

class Group(): 
    group_name 

class Post(): 
    post_content 

Что является наиболее эффективным способом, чтобы связать эти данные с точки зрения масштабируемости базы данных и производительности?

1) Свяжите каждое сообщение с пользователем и группой. Когда пользователь просматривает группу, выберите все записи из таблицы Post, где Group ID = текущая группа. Когда пользователь просматривает свою домашнюю страницу, посмотрите, к каким группам принадлежит пользователь, и найдите всех других пользователей, принадлежащих к этой группе. Затем вытащите все сообщения от этих пользователей.

2) Свяжите все должности с пользователем. Когда пользователь просматривает свою домашнюю страницу, посмотрите, к каким группам принадлежит пользователь, и найдите всех других пользователей, принадлежащих к этой группе. Затем вытащите все сообщения от этих пользователей. При просмотре страницы группы найдите всех пользователей этой группы, а затем потяните все сообщения, связанные с этими пользователями.

3) Создайте таблицу соединений, которая имеет PostID, UserID и GroupID. При просмотре группы найдите все сообщения, которые имеют GroupID, и потяните эти сообщения. При просмотре домашней страницы вошедшего пользователя найдите все группы, к которым принадлежит пользователь, а затем найдите всех пользователей, принадлежащих к этим группам, а затем потяните все сообщения для этих пользователей.

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

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

+0

в 2) решении, группы, в которых находятся должности, не могут быть определены без пользователя, это правильно в вашей бизнес-модели? Если группы, принадлежащие пользователям, меняются, группы, принадлежащие к сообщениям, тоже меняются. – 2010-12-09 02:33:24

ответ

1

Вы не указали, какие у вас есть.

С базой данных ISO/IEC/ANSI SQL, которая имеет встроенную систему безопасности (разрешений), вам не нужно ничего, просто установите разрешения с помощью средства SQL.Он является внутренним и очень быстрым.

Если вам нужна производительность, масштабируемость и целостность данных, вам нужно отказаться от идеи для объектов и классов и немного узнать о реляционных базах данных. Кроме того, если вы моделируете свои данные как реляционную базу данных (а не как классы объектов), 90% ваших вопросов выше не будут существовать.

Если вы не понимаете, что я говорю, прочитайте это recent post (начиная с заголовка 11 декабря 10).

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

Да, абсолютно. Это не имеет смысла. Имеет смысл правильно моделировать данные, потому что нормализованная модель намного быстрее. Это приводит к большему количеству меньших таблиц, а не к меньшему количеству жировых таблиц; арифметика и законы физики. Отсутствие дублирования данных означает отсутствие аномалий обновления, что означает, что транзакции меньше и с меньшей вероятностью блокируются (вы хотите разрешить одновременный доступ нескольких пользователей, правда?).

Кроме того, ваше кодирование будет затруднено, так как вы не можете понять, как данные относятся к другим данным. Бросьте свои сущности (содержимое данных всех ваших страниц) в свой вопрос (отредактируйте его и добавьте в него), и мы можем пойти. Я могу видеть User, Group, Post, но как насчет Wall; любая другая мебель; Photos, Albums.

Смежные вопросы