mysql - modelos - llaves foraneas ruby on rails

Rails-Tablas de bases de datos compartidas entre dos aplicaciones

Question

En breve lanzaremos una aplicación de Rails complementaria a nuestra aplicación Rails existente. Ejecutaremos la aplicación complementaria junto con nuestra aplicación existente en los mismos servidores.

Mi pregunta se refiere a las bases de datos. Mi proveedor de alojamiento generalmente configuraría una segunda base de datos distinta para la nueva aplicación: secondappname_production. Sin embargo, hay una serie de tablas compartidas entre las aplicaciones. Estas tablas compartidas también son mantenidas por una serie de trabajos cron. Me encantaría evitar la duplicación de estas tablas (y, por lo tanto, las tareas cron) si es posible.

¿Hay alguna manera de poner estas tablas compartidas en una base de datos compartida que ambas aplicaciones de Rails puedan aprovechar? ¿Alguna sugerencia sobre cómo configurar eso o documentación punteros?

¡Muchas gracias!

EDITAR: Para aclarar por qué no quiero ejecutar ambas aplicaciones desde el mismo DB: Ambas aplicaciones tienen modelos con el mismo nombre (pero con atributos diferentes de los modelos, etc.), por lo que preferiría no ejecutar ambos. el mismo DB ....

Answer 1

Creo que lo que quiere es compartir el modelo, no solo la tabla de la base de datos, en la tabla de rieles se basa en el modelo.

create main rails app -->rake g model User name:string->rake db:migrate

create shared rails app 
-->rake sync:copy 
-->(DO NOT generate same model in shared app, also do not db:migrate)
-->config/generater shared
controller and router.rb file(dependend your requirement)

sync.rake (aplicación / lib / tareas /)

namespace :sync do

      desc ''Copy common models and tests from Master''
      task :copy do
        source_path = ''/Users/ok/github/appDataTester/appmain''
        dest_path = ''/Users/ok/github/appDataTester/appshared''

        # Copy all models & tests
        %x{cp #{source_path}/app/models/*.rb #{dest_path}/app/models/}
        %x{cp #{source_path}/test/models/*_test.rb #{dest_path}/test/models/}

        # Fixtures
        %x{cp #{source_path}/test/fixtures/*.yml #{dest_path}/test/fixtures/}

        # Database YML
        %x{cp #{source_path}/config/database.yml #{dest_path}/config/database.yml}
      end
    end

Answer 2

Puede tener algunos modelos en una base de datos (los que desea compartir) y otros en la propia base de datos de la nueva aplicación (para que no entren en conflicto con la aplicación existente).

Para especificar una base de datos diferente para un modelo en particular, intente algo como esto:

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

Ahora, usa esto como una clase base para tus modelos compartidos, y deberías estar listo.

Parte de su pregunta son las mejores prácticas, así que un par de otras opciones.

Una opción es no intentar siquiera acceder directamente a la base de datos, sino crear una integración entre las aplicaciones utilizando ActiveResource. Haga que la aplicación original proporcione una interfaz REST para estas tablas, que la consuman en la nueva aplicación y no comparta la db en absoluto. Me gusta esta opción, pero puede que no sea inteligente para su situación.

Otra opción es refactorizar estas tablas compartidas en su propia base de datos y tener acceso a las aplicaciones de ambos rieles en esa base de datos. Incluso podría terminar escribiendo servicios (p. Ej., Una interfaz tranquila) a estos datos compartidos para que los utilicen ambas aplicaciones, y luego quedará bien desconectado.

Considere las complejidades de cuando esta estructura de db compartida cambia. Si está compartiendo las tablas directamente, es posible que las aplicaciones de ambos rieles deban cambiarse simultáneamente para adaptarse al cambio; ahora ha vinculado su programa de lanzamiento, estas aplicaciones ahora están acopladas. Si ajusta el acceso a la base de datos en servicios, esto puede proporcionar una abstracción, ya que puede servir tanto a la estructura anterior como a la nueva estructura al implementar el nuevo servicio actualizado al mismo tiempo que la interfaz de servicio anterior. Todo depende de tu aplicación si tal complejidad vale la pena.