Как сегментировать базу данных для приложения, обращающегося к ней (иначе говоря, проблема с одной базой данных для нескольких пользователей)?

Question

Я создал веб-приложение для одного пользователя, но теперь я хотел бы предложить его многим пользователям (это приложение для фотографа).

Проблемы с несколькими базами данных

Сначала я сделал это, создав приложение для каждого пользователя, но у него много проблем, например:

• Предоставление доступа новому пользователю не может быть автоматизировано (или очень сложно), поскольку мне приходитсясоздать поддомен, базу данных, исходные таблицы, скопировать код в новое место и т. д. Это утомительно делать вручную!
• Я не могу так легко создавать отчеты и статистику использования, например, сколько проектову моих пользователей, сколько фотографий и т. д.

Проблемы с одной базой данных

Но наличие только одной базы данных для каждого пользователя создает свои собственные проблемы в коде:

• Теперь мне нужно изменить схему БД для размещения дополнительных пользователей, например, в таблице проектов, содержащей столбец user_id (то же самое касается некоторых других таблиц, таких как настройки и т. Д.).
• Мне нужно взглянуть напочти всеch строка кода, которая обращается к базе данных и редактирует SQL для выбора и вставки, так что я сохраняю данные для этого конкретного пользователя, в то же время делая соединения, чтобы проверить разрешения (select ... from projects inner join project_users ... where user_id = ?).
• Если я забуду сделать это в одном месте кода, это будет означать нарушение безопасности или другую неприятную вещь (рассмотрите возможность показа проектов пользователя, просто выполнив select * from projects, как я это делал - он покажет проекты всех пользователей).
• Резервное копирование : резервное копирование сложнее, потому что есть больше данных для всей базы данных, и если пользователь говорит: «Эй, я допустил ошибку сегодня, вы можете вернуть БД на вчерашний день», я не могу каклегко сделать это.

Решение?

Я прочитал несколько вопросов по stackoverflow и решил, что мне следует пойти по пути «единой базы данных».Но я бы хотел избавиться от проблем, если это возможно.Поэтому я подумал, есть ли способ как-то сегментировать мою базу данных, чтобы я не получил эти неприятные (иногда невидимые) ошибки?При необходимости я могу перепрограммировать слой доступа к БД, но я использую SQL, а не методы получения и установки OO.Любая помощь будет принята с благодарностью.

Answer 1

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

Во-первых, в вашем новом проекте можно использовать другого пользователя MySQL и запретить этому пользователю «выбирать» права на таблицы, доступ к которым возможен только через объединения с таблицей «пользователи». Затем вы можете создать представление, которое объединяет две таблицы, и использовать его всякий раз, когда вы запускаете запросы "select". Таким образом, если вы забудете запрос, он произойдет эффектно, а не тихо. Конечно, вы также можете ограничить вставку, обновление и удаление таким способом - хотя это намного сложнее с представлением.

Редактировать Таким образом, если ваше приложение в настоящее время подключается как «web_user», вы можете отменить выборочный доступ к таблице проектов у этого пользователя. Вместо этого вы должны создать представление «projects_for_users» и предоставить полномочия «выбрать» для этого представления новому пользователю - «фотографу», возможно. Новый пользователь также не должен иметь права доступа к «проектам».

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

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

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

Редактировать Предоставление - это слово для настройки службы для нового пользователя (я думаю, что это происходит из мира телефонии, где телефонные компании будут говорить о предоставлении новой услуги на существующей телефонной линии). Обычно он включает в себя целую кучу бизнес-процессов - и каждый шаг в этом процессе должен быть успешным, чтобы начать следующий. Таким образом, в вашем приложении вам может потребоваться настроить новую учетную запись пользователя, проверить его адрес электронной почты, настроить пространство для хранения и т. Д. Каждый из этих шагов должен рассматриваться как шаг в процессе, а не просто как одна задача.

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

Answer 2

Ну, пора взглянуть на некоторые неопровержимые факты - я думаю.«Проблема единой базы данных», которую вы описываете, - это не проблема, а обычный (обычный) дизайн.Довольно часто one - это просто особый случай many .

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

Итак, пришло время изменить дизайн.