Я разрабатываю проект, который может потребовать тысячи записей для каждого администратора (по моим оценкам, через пару лет я увижу более 100 000 записей в базе данных), и все записи уникальны для каждого администратора. (т.е. я никогда не должен получать доступ к вашим данным, и вы никогда не должны получать доступ к моим). Каждый администратор может создать несколько пользователей, которые предоставляют им доступ к определенным данным, но только к тем данным, которые не входят в их группу разрешений. Какова наилучшая организационная стратегия для «больших данных» в этом смысле?
Представьте, что мой проект должен помочь финансовому консультанту и клиенту отслеживать все их покупки. Финансовый консультант может просматривать информацию обо всех своих клиентах. Каждый дополнительный клиент может просматривать только информацию о своих клиентах (если не предоставлены иные разрешения). и несколько финансовых консультантов могут использовать одно и то же программное обеспечение, работающее на централизованном сервере. Единственное предположение, которое мы должны сделать, состоит в том, что каждая покупка — это объект, который может содержать значительный объем данных.
Скорее всего, у меня будет БД для входа в систему и информации о сертификате. но как только пользователь вошел в систему, предположим, что у него есть UserID.
Используя этот идентификатор пользователя, я знаю, что могу отслеживать разрешения объекта (на стороне сервера). Но если у меня есть более 100 000 записей, я могу увидеть проблемы с производительностью при попытке получить все записи, к которым у конкретного пользователя есть доступ при входе в систему. Я, вероятно, буду использовать React с хранилищем Redux, так что, как только я получу все свои данные один раз, мне не нужно будет беспокоиться о последовательном извлечении данных (я также могу добавить флаг в базу данных, который позволяет пользователю знать, соответствуют ли его данные дата).
Это моя мысль:
ПРИМЕЧАНИЕ. У меня есть мысль использовать для этого базу данных SQL, если вы считаете иначе, пожалуйста, укажите это!
Спасибо!
Я проголосовал за закрытие на основе мнения. Тем не менее, с базой данных SQL все в порядке, и количество записей небольшое, а не большое.
Для больших наборов данных я бы предложил секционирование и индексирование таблиц. Проверьте секционированные таблицы и индексы для БД Oracle, то же самое можно сделать и для других БД SQL.
Единственная проблема с этим ответом заключается в том, что 100 000 записей не являются большими данными, и, за исключением некоторых крайних случаев, никогда не рассматривают возможность разделения таких данных.
«более 100 000 записей» на самом деле не «большие данные». Две базы данных могут быть плохой идеей, поскольку обеспечение ссылочной целостности между базами данных может быть сложным или невозможным. Но это очень расплывчатый вопрос или на него нельзя ответить кратко. Поэтому я считаю, что это не по теме здесь. Возможно, вы захотите провести небольшое исследование и разбить проблему на более мелкие фрагменты, о которых вы можете спросить. Или наймите консультанта, который проведет вас через это.