>
> Hola otra vez lista!
>>>>
>>>> Disculpes mis molestias :-P
>>>>
>>>> Quería ver si a alguno se le ocurre una manera mejor de resolver lo
>>>> siguiente:
>>>>
>>>> Cuál es la mejor manera de unir en una misma tabla elementos de varios
>>>> modelos?
>>>>
>>>> Por ahora lo resolví "sumando" las diferentes asociaciones con un map{}
>>>> que arma hashes igual.es
>>>>
>>>> class Person << ActiveRecord::Base
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ...
>>>> def dashboard
>>>> ds = self.interviews.all.map{|i| {:when => i.when, :observations =>
>>>> i.obs}} +
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> self.followups.all.map{|f|{:when => f.date, :observations =>
>>>> f.notes}} + ....
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> return ds
>>>> end
>>>> ...
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> end
>>>>
>>>> Por ahora funciona, pero definitivamente tiene que haber una manera
>>>> mejor :-P
>>>>
>>>> Un problema, por ejemplo, es que a esto no le puedo aplica will_paginate
>>>> con facilidad.
>>>>
>>>
>>> Por un lado, resolverlo de esta manera va a ser siempre complicado.
>>> Podrías "ayudar" a ActiveRecord escribiendo partes del SQL a mano (pero no
>>> creo que el resultado sea bueno, habría que ver cómo lo vas a usar, dudo que
>>> logres hacerlo transparente).
>>>
>>> Pero me huele a que hay algún problema de diseño. En principio, si es
>>> común que necesites tratar a estas dos entidades de manera polimórfica, como
>>> si fuesen lo mismo, y las entidades (Interview y Followup) tienen estructura
>>> y responsabilidades en común, sería preferible utilizar STI (Single Table
>>> Inheritance, usarías herencia en tus clases de Ruby y en la tabla estarían
>>> las columnas de las dos entidades, además de una columna "type" que los
>>> discrimina).
>>>
>>> En caso de que no tenga sentido usarlas polimórficamente (por que son dos
>>> entidades bien distintas), probablemente lo que esté faltan sea factorizar
>>> un entidad entidad en común (con lo que veo, se me ocurre Event que tiene
>>> when y notes, de manera). Aquí usarías un has_many polimórfico, esto es,
>>> Interview.has_many :events, :as => :schedulable, Followup.has_many
>>> :events, :as => :schedulable y Event.belongs_to :schedulable,
>>> :polymorphic => true). De esta manera podés listar Events sin problemas
>>> (sentite libre de elegir un mejor nombre que schedulable).
>>>
>>> Depende de tus requerimientos. Lo importante es que si necesitás
>>> manejarlos "juntos" lo reflejes en la estructura de tu modelo.
>>>
>>> Saludos,
>>>
>>> Nacho
>>>
>>> _______________________________________________
>>>
>>
>> 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.
>
> 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.
>
> 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?
>
> Muchas gracias por la ayuda.
>
>
Los UNION se hacen sobre SELECT, donde podés ponerle los nombres que quieras
a los campos. Si los nombres de los campos coinciden entonces son el mismo
campo en el UNION, donde algunos registros vienen de un SELECT y otros de
otros. Pero hay algunos detalles de varían dependiendo del motor de base de
datos que estés usando, así que vas a tener que fijarte.
Por otro lado, si usás migraciones podés hacer la VIEW desde ahí.
_______________________________________________
Ruby mailing list
[email protected]
http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar
