2010/7/31 Instr. Dwayne Macgowan <[email protected]> > 2010/7/31 Aureliano Calvo <[email protected]> > >> Lo que yo haría es hacer una vista en la base de datos (de esas que se >> hacen con CREATE VIEW) y mapearía esa vista, como si fuese una tabla, en una >> clase que hereda de ActiveRecord::Base. Entonces will_paginate debería andar >> transparentemente, ya que para Rails esa vista sería igual que una tabla >> común. >> >> Mis 2 centavos, >> Aureliano. >> >> _______________________________________________ >> Ruby mailing list >> [email protected] >> http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar >> >> > La verdad que sí hay algunos problemas de diseño en la base. Es un proyecto > que empecé cuando estaba aprendiendo rails medio jugando y como quién no > quiere la cosa se convirtió en mi fuente de ingresos principal. Cargo igual > con muchos errores del comienzo. >
Rails en este sentido te hace bastante sencillo el refactoreo... lo más complicado que queda es migrar datos, en donde suelen aparecer casos que no son fáciles de migrar a una nueva estructura. > Algunos modelos puedo unificarlos con STI, de hecho fue lo que hice antes > de crear este dashboard. Pero tengo otros que son de naturaleza bastante > diferente, o sobre los cuales hago cálculos intensos y me parece mejor > mantenerlos en tablas separadas. En este dashboard quiero juntar toda esa > información. Para esto me gustó lo de factorizar una entidad común. Lo voy a > ver un poco porque no se si lo entiendo del todo, pero parecería la mejor > solucion. > Por esto que decís puede ser que encuentres que el "aspecto en común" de algunas entidades sea demasiado trivial como para darle una nueva entidad (siempre a criterio tuyo por supuesto, pero por ejemplo si lo único que tienen en común es "tienen precio" por ahí no vale la pena extraer algo de ahí). Por otro lado, me parece que si los cálculos son muy intensivos, y dependiendo por supuesto del volumen de datos que manejen, es probable que la base de datos no de a basto más temprano que tarde. Probablemente debas ir pensando en otra solución (tener algunos models con data estadística y crearlos o actualizarlos offline a la noche por ejemplo o a demanda, pero por backend) > Crear un view también es buena. Se haría con UNION no? Pero creo que para > eso las tablas que *mergee* tienen que tener las mismas columnas. ¿o no es > asi? > buena idea la de Aureliano -- si la base se banca el volumen de datos parece ser la más barata no? saludos Nacho
_______________________________________________ Ruby mailing list [email protected] http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar
