Uso de procedimientos almacenados en rieles

Question

Como dije en una publicación anterior, nuestra aplicación Rails tiene que interactuar con un tipo de tabla E-A-V en una aplicación de terceros de la que estamos extrayendo datos. Creé una Vista para hacer que los datos fueran normales, pero lleva demasiado tiempo ejecutarlos. Hicimos que uno de nuestros desarrolladores de PHP offshore creara un procedimiento almacenado para ayudar a acelerarlo.

Ahora nos topamos con la cuestión de que tenemos que llamar a este procedimiento almacenado desde la aplicación Rails, así como proporcionar búsqueda y filtrado. La vista podría hacer esto porque Rails lo estaba tratando como un modelo tradicional de Rails. ¿Cómo podría hacer esto con el proceso almacenado? ¿Tendríamos que escribir búsquedas y pedidos personalizados (estábamos usando Searchlogic)? La administración es incapaz de comprender los inconvenientes de usar un proceso almacenado de Rails; todo lo que dicen es que el método actual está tardando demasiado en cargar los datos y debe ser reparado, pero la búsqueda y el filtrado son funciones fundamentales.

EDIT He publicado el código para esta consulta aquí: Optimizing a strange MySQL Query. Lo que es gracioso es que cuando ejecuto esta consulta en una GUI (Navicat) se ejecuta en aproximadamente 5 segundos, pero en la página web tarda más de un minuto en ejecutarse; la vista es complicada por las razones que describo en la publicación original, pero creo que MySQL optimiza y almacena en caché las vistas como lo hace SQL Server (o mejor dicho, cómo leo ese SQL Server) para mejorar el rendimiento.

Answer 1

Puede llamar a procedimientos almacenados desde Rails, pero va a perder la mayoría de los beneficios de ActiveRecord, ya que el SQL generado estándar no funcionará. Puede usar la conexión de base de datos nativa y llamarla, pero va a ser una abstracción con goteras. Es posible que desee considerar DataMapper.

Mirando hacia atrás en su última pregunta, me gustaría obtener el DBA para crear un disparador para crear una estructura más relacional a partir de los datos. El disparador insertaría los datos de EVA en una tabla, que es la única forma que conozco de hacer vistas materializadas en MySQL. De esta forma, solo paga un pequeño costo de fondo incremental en la inserción, y la aplicación puede ejecutarse normalmente.

En fin ...

ActiveRecord::Base.connection.execute("call SP_name (#{param1}, #{param2}, ...)") 

Pero hay una open ticket out there on lighthouse que indica que este enfoque puede no funcionar con a cambiar algunos de los parámetros a utilizar la conexión.