Каков наиболее эффективный способ указания пользовательских разрешений в базе данных? - PullRequest
0 голосов
/ 08 декабря 2010

У меня есть приложение, которое связывает пользователей с определенными группами в стиле Facebook.

Например:

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

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

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

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

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

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

class User():
    user_name
    first_name
    last_name

class Group():
    group_name

class Post():
    post_content

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

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

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

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

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

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

1 Ответ

1 голос
/ 11 декабря 2010

Вы не указали, какие у вас дбм.

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

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

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

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

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...