PHP Lang
  1. PHP Lang
  3. Нужно обновить мою базу данных одного пользователя, чтобы позволить нескольким пользователям, как изменить схему базы данных?
Intereting Posts
Получить формат даты в соответствии с языком в PHP php mysql – следует ли добавить поле «category-name» в таблицу или нет? Как разрешить кодированные символы URI в URL-адресах CodeIgniter? Рекурсивное меню PHP в структуре списка HTML Query Logic SQL Многомерный массив для массива Почему in_array () возвращает неожиданные / странные результаты? Symfony2 – Twig – Как отправить параметры родительскому шаблону? Вставка значения Integer в mysql int с помощью INSERT php: нажатие на массив, который может или не может существовать Как можно разделить результаты поиска на вкладки «Типы сообщений» на Frontend? PHP: HTTP Basic – Выход из системы Почему я не могу получать сообщения от GCM на устройстве Android Laravel 5.3 – Как сохранить сообщение сеанса до тех пор, пока пользователи не выйдут из системы Создание метода конструктора в контроллере в Yii

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

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

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

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

Моя мысль заключалась в том, чтобы создать таблицу «учетных записей» и привязать «account_id» к каждой таблице. Это хороший подход? Я прикрепил схему, чтобы вы могли видеть, что у меня есть до сих пор!

Примечание. Я создаю это в Codeigniter (php) и MySQL.

введите описание изображения здесь

Solutions Collecting From Web of "Нужно обновить мою базу данных одного пользователя, чтобы позволить нескольким пользователям, как изменить схему базы данных?"

Несколько клиентов; одно размещенное приложение. Вы описываете базу данных с несколькими арендаторами.

Когда вы создаете базу данных с несколькими арендаторами, вам необходимо рассмотреть

  • Запросы
  • Стоимость
  • изоляция и защита данных
  • обслуживания и
  • аварийное восстановление.

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

«Без общего доступа», «отдельная база данных» или одна база данных для каждого арендатора

  • Самый дорогой клиент. (Большое количество клиентов подразумевает большое количество серверов.)
  • Наивысшая степень изоляции данных.
  • Аварийное восстановление для одного арендатора является простым и понятным.
  • Техническое обслуживание теоретически сложнее, потому что изменения должны выполняться в каждой базе данных. Но ваши dbms могут легко поддерживать запуск хранимых процедур в каждой базе данных. (Например, SQL Server имеет недокументированную системную хранимую процедуру, например sp_msforeachdb. Возможно, вы можете написать свой собственный.) «Без общего доступа» также является наиболее легко настраиваемым, но это также вызывает дополнительные проблемы с обслуживанием.
  • Наименьшее количество строк в таблице. Скорость запроса близка к оптимальной.

«Все разделено» или «общая схема» или «одна база данных на планету»,

  • Наименее дорогой для арендатора.
  • Самая низкая степень изоляции данных. Каждая таблица имеет столбец, который идентифицирует, к какому арендатору принадлежит строка. Поскольку ряды арендаторов смешиваются в каждой таблице, относительно просто случайно представить другие данные арендатора.
  • Аварийное восстановление для одного арендатора относительно сложно; вам необходимо восстановить отдельные строки во многих таблицах.
  • Структурное обслуживание проще, учитывая, что все арендаторы используют таблицы. Это увеличивает нагрузку на связь, хотя, поскольку вы должны общаться и координировать каждое изменение с каждым арендатором. Это легко настраивается.
  • Наибольшее количество строк в таблице. Быстрый запрос сложнее, но зависит от количества арендаторов и количества строк. Вы могли бы легко опрокинуться на территорию VLDB.

Между «shared nothing» и «shared all» находится «общая схема».

«Общая схема»

  • Арендаторы делят базу данных, но у каждого арендатора есть собственная именованная схема. Стоимость падает между «общим ничем» и «разделяет все»; большие системы обычно нуждаются в меньшем количестве серверов, чем «ничего общего», больше серверов, чем «разделяли все».
  • Гораздо лучшая изоляция, чем «разделял все». Не так много изоляции, как «ничего общего». (Вы можете назначить разрешения и REVOKE для схем.)
  • Аварийное восстановление для одного арендатора требует восстановления одной из многих схем. Это либо относительно легко, либо довольно сложно, в зависимости от ваших dbms.
  • Обслуживание легче, чем «ничего общего»; не так просто, как «разделять все». Относительно просто написать хранимую процедуру, которая будет выполняться в каждой схеме в базе данных. Легче распространять общие таблицы среди арендаторов, чем с «общим ничем».
  • Обычно более активные арендаторы на сервер, чем «ничего общего», что означает, что они делят (деградируют) больше ресурсов. Но не так плохо, как «разделять все».

У Microsoft есть хорошая статья о многопользовательской архитектуре с более подробной информацией. (Ссылка на одну страницу многостраничного документа.)