Должен ли я использовать несколько баз данных?

Question

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

Я нашел это сообщение http://programmerassist.com/article/302 Но я хотел бы прочитать больше мыслей по этому вопросу. Я должен решить между MySQL и PosgreSQL, какая база данных лучше подходит для моей проблемы.

Answer 1

Существует несколько вариантов работы с мультитенантным приложением.

Во-первых, вы можете добавить область к вашим таблицам (как предложено Чедом Бёрчем - используя company_id). Для большинства случаев использования это хорошо. Если вы обрабатываете данные, которые являются безопасными / конфиденциальными (например, учетная информация), вам нужно быть очень осторожным при тестировании, чтобы гарантировать, что данные остаются конфиденциальными.

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

Если вы используете PostgreSQL, вы можете сделать что-то подобное, используя схемы. Схемы PostgresQL предоставляют очень удобный способ изолировать ваши данные от разных клиентов. База данных содержит одну или несколько именованных схем, которые в свою очередь содержат таблицы. Вам нужно добавить несколько смартов в ваши миграции и развертывания, но это работает очень хорошо.

Внутри приложения Rails вы прикрепляете фильтры к запросу, которые включают или отключают схему текущего пользователя.

Что-то вроде:

before_filter :set_app

def set_app
  current_app = App.find_by_subdomain(...)
  schema = current_app.schema

  set_schema_path(schema)
end 


def set_schema_path(schema)
  connection = ActiveRecord::Base.connection
  connection.execute("SET search_path TO #{schema}, #{connection.schema_search_path}")
end

def  reset_schema_path
  connection = ActiveRecord::Base.connection
  connection.execute("SET search_path TO #{connection.schema_search_path}")
end

Answer 2

Проблема с ответами о нескольких базах данных заключается в том, что они приходят от людей, которые не нуждаются или не имеют опыта работы с несколькими базами данных. Вторая проблема заключается в том, что некоторые базы данных просто не позволяют переключаться между несколькими базами данных, в том числе позволяют пользователям выполнять собственное резервное копирование и восстановление, а также включают масштабирование для указания некоторых пользователей на другой сервер данных. Вот ссылка на полезное видео http://aac2009.confreaks.com/06-feb-2009-14-30-writing-multi-tenant-applications-in-rails-guy-naor.html

Эта ссылка поможет с Ruby on Rails с Postgresql.

В настоящее время у меня есть мультитенант, многопользовательская база данных, несколько пользователей (много входов в систему к одному и тому же арендатору с разными уровнями доступа), и я работаю в режиме онлайн-приложения SaaS. На самом деле есть два приложения, одно из которых относится к категории учета, а другое - к банковскому делу. Оба приложения построены на одной структуре и методах. Клиент-пользователь (арендатор) может переключать базы данных под входом этого пользователя. Пользователь-агент, такой как налоговый бухгалтер, может переключаться между базами данных только для своих клиентов. Суперпользователь может переключиться на любую базу данных. Существует один словарь данных, то есть только одно место, где определены таблицы и столбцы. Есть глобальные данные и локальные данные. Глобальные данные, такие как основной план счетов, который доступен каждому (только для чтения). Локальные данные - это база данных пользователя. Новый пользователь может получить клон главной базы данных. Есть несколько клонов на выбор. Суперпользователь может поддерживать базы данных клонов.

Проблема в том, что он находится в COBOL и использует файлы ISAM и использует метод CGI. Проблема в том, что: а) существует ощущение, что КОБОЛ устарел, б) привлечение обученных людей, в) цена и г) онлайн-помощь. В противном случае это работает, и я доволен этим.

Итак, я исследую, чем его заменить и что это за минное поле.

Answer 3

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

# app/models/organisation.rb
class Organisation < ActiveRecord::Base
  self.table_name = 'common.organisations'
  # set relationships as usual
end

# app/models/user.rb    
class User < ActiveRecord::Base
  self.table_name = 'common.users'
  # set relationships as usual
end

Тогда для миграций я сделал это с помощью этого замечательного учебника. http://timnew.github.com/blog/2012/07/17/use-postgres-multiple-schema-database-in-rails/ используйте это, это намного лучше, чем то, что я видел в других местах, даже то, что Райан Бейтс делал на железнодорожных передачах.

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

Answer 4

Нет, вы не должны использовать несколько баз данных.

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

Скорее всего, вы просто хотите добавить в свои таблицы столбец типа "id компании", чтобы определить, к какой компании принадлежит данная запись.