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

Question

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

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

Answer 1

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

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

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

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

Внутри приложения 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

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

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

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

Answer 3

Проблемы с ответами о нескольких базах данных, когда они приходят от людей, которые не имеют потребности или опыт работы с несколькими базами данных. Вторая проблема заключается в том, что некоторые базы данных просто не позволяют переключаться между несколькими базами данных, в том числе позволяя пользователям выполнять собственную резервную копию и восстановление, включая масштабирование, чтобы указать некоторых пользователей на другой сервер данных. Вот ссылка на полезное видео 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. Проблема в том, что: a) есть мнение, что COBOL устарел, b) получить обученных людей, c) цену и d) онлайн-помощь. В противном случае это работает, и я доволен этим.

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

Answer 4

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

# 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/ используйте это, это лучше, чем то, что я видел в других местах, даже так, как это делал Райан Бейтс на railscasts.

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