Рельсы - Общие Таблицы базы данных между двумя приложениями

Мы будем выпускать вскоре сопутствующее применение Рельсов к нашему существующему приложению Рельсов. Мы будем запускать сопутствующее приложение вместе с нашим существующим приложением на тех же серверах.

Мой вопрос касается баз данных. Мой принимающий поставщик обычно настраивал бы 2-ю отличную базу данных для нового применения - secondappname_production. Однако есть ряд общих таблиц между заявлениями. Эти общие столы также сохраняются серией рабочих мест крона. Я хотел бы постараться не дублировать эти столы (и таким образом рабочие места крона) если вообще возможный.

Есть ли способ, которым я могу вставить эти общие столы, возможно, общая база данных, которую могут усилить оба приложения Рельсов? Какие-либо предложения относительно того, как настроить это или указатели документации?

Большое спасибо!

Править: Чтобы разъяснить, почему я не хочу запускать оба приложения из той же DB: у Обоих приложений есть модели того же имени (все же различные признаки моделей, и т.д.), таким образом, я предпочел бы не управлять обоими из той же DB....

16
задан shedd 12 January 2010 в 03:09
поделиться

1 ответ

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

Чтобы указать другую базу данных для определенной модели, попробуйте что-нибудь вроде этого:

class SharedModelBase < ActiveRecord::Base
  self.abstract_class = true
  establish_connection(ActiveRecord::Base.configurations["shared_db_connection_#{RAILS_ENV}"])
end

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

Частью вашего вопроса является лучшая практика, так что пара других вариантов.

Один из вариантов - это даже не пытаться получить прямой доступ к db, а построить интеграцию между приложениями с помощью ActiveResource. Пусть оригинальное приложение предоставит RESTful интерфейс к этим таблицам, и использует его в новом приложении, а db вообще не будет совместно использоваться. Мне нравится этот вариант, но он может быть не очень умным в вашей ситуации.

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

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

24
ответ дан 30 November 2019 в 21:45
поделиться
Другие вопросы по тегам:

Похожие вопросы: