Как сделать пользовательскую CMS многопользовательской

Question

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

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

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

Как это обычно достигается?

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

Можно ли каким-то образом разделить базы данных, не удваивая работу, если я изменю структуру таблицы в будущем или добавлю дополнительные поля и т. Д.?

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

unique_id    |      title    |      modified_date       |      content
  xx                hello           0000-00-00 00:00:00       i am content     

Лучшее, что я могу себе представить, это то, что тогда это станет:

client_id     |    unique_id    |      title    |      modified_date       |      content
 xx                  xx                hello           0000-00-00 00:00:00       i am content     

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

Answer 1

Храните его как единую базу данных с добавленным столбцом client_id.Если он становится большим со многими клиентами, разделите таблицы по LIST: http://dev.mysql.com/doc/refman/5.5/en/partitioning-list.html

Горизонтальное разбиение позволяет вам разделить одну логическую таблицу, поэтому, когда ваш SQL включает «... WHERE client_id= 1 ", ему нужно будет только прочитать индекс (ы) или раздел, содержащий данные" client_id = 1 ".Другие разделы игнорируются, как будто у вас есть отдельная таблица для каждого client_id.

ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: Я не использовал разделение в MySQL.Я просто знаком с концепцией от Oracle.Убедитесь, что ваш механизм хранения MySQL поддерживает разбиение: http://dev.mysql.com/doc/refman/5.5/en/partitioning.html

Answer 2

У меня похожая ситуация с моим веб-приложением: многие пользователи используют одну базу данных, где в большинстве таблиц есть идентификатор клиента. Это не CMS, но достаточно похожи, пользователи выполняют операции CRUD со своими данными.

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

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

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

Answer 3

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