Pregunta

Lo que quiero hacer es muy simple, pero estoy tratando de encontrar la mejor o más elegante forma de hacerlo. La aplicación Rails que estoy construyendo ahora tendrá un horario de clases diarias. Para cada clase, los campos relevantes para esta pregunta son:

  • Día de la semana
  • Hora de inicio
  • Tiempo final

Una sola entrada podría ser algo como:

  • día de la semana: miércoles
  • hora de inicio: 10:00 am
  • hora de finalización: mediodía

También debo mencionar que es una aplicación bilingüe Rails 2.2 y estoy usando la función nativa i18n Rails. De hecho, tengo varias preguntas.

Con respecto al día de la semana, ¿debería crear una tabla adicional con una lista de días, o hay una forma integrada de crear esa lista sobre la marcha? Tenga en cuenta que estos días de la semana deberán presentarse en inglés o español en la vista de programación según la variable de configuración regional.

Al consultar el horario, tendré que agrupar y ordenar los resultados por día de la semana, de lunes a domingo, y, por supuesto, ordenar las clases dentro de cada día por hora de inicio.

Con respecto a la hora de inicio y la hora de finalización de cada clase, ¿utilizaría campos de fecha y hora o campos enteros? Si este último, ¿cómo implementaría esto exactamente?

Estamos ansiosos por leer las diferentes sugerencias que ustedes harán.

¿Fue útil?

Solución

Simplemente almacenaría el día de la semana como un número entero. 0 = > Lunes ... 6 = > Domingo (o de la forma que desee. Es decir, 0 = > domingo). Luego almacene la hora de inicio y la hora de finalización como Hora.

Eso facilitaría la agrupación. Todo lo que tendría que hacer es ordenar por día de la semana y hora de inicio.

Puede mostrar esto de varias maneras, pero esto es lo que haría.

  1. Tiene funciones como: @sunday_classes = DailyClass.find_sunday_classes que devuelve todas las clases para el domingo ordenadas por hora de inicio. Luego repita para cada día.

    def find_sunday_classes
      find_by_day_of_week(1, :order -> 'start_time')
    end

    Nota: find_by probablemente debería tener una identificación al final, pero eso es solo preferencia en cómo desea nombrar la columna.

  2. Si desea la semana completa, llame a los siete desde el controlador y repítalos en la vista. Incluso podría crear páginas de detalles para cada día.

  3. La traducción es la única parte difícil. Puede crear una función auxiliar que tome un número entero y devuelva el texto para el día apropiado de la semana basado en local.

Eso es muy básico. Nada complicado.

Otros consejos

Si sus datos son una Hora, entonces los almacenaría como una Hora; de lo contrario, siempre tendrá que convertirlos fuera de la base de datos cuando realice operaciones relacionadas con la fecha y la hora. El día son datos redundantes, ya que formarán parte del objeto de tiempo.

Esto debería significar que no necesita almacenar una lista de días.

Si t es un tiempo, entonces

t.strftime('%A')

siempre te dará el día como una cadena en inglés. Esto podría ser traducido por i18n según sea necesario.

Por lo tanto, solo necesita almacenar la hora de inicio y la hora de finalización, o la hora y la duración de inicio. Ambos deberían ser equivalentes. Tendría la tentación de almacenar el tiempo de finalización yo mismo, en caso de que necesite hacer manipulaciones de datos en los tiempos de finalización, que por lo tanto no tendrán que calcularse.

Creo que la mayoría del resto de lo que usted describe también debería caerse del almacenamiento de datos de tiempo como instancias de Time.

Ordenar por día de la semana y hora solo será cuestión de ordenar por su columna de tiempo. es decir

daily_class.find(:all, :conditions => ['whatever'], :order => :starting_time)

Agrupar por día es un poco más complicado. Sin embargo, esta es una excelente publicación sobre cómo agrupar por semana. La agrupación por día será análoga.

Si está tratando con volúmenes de datos no triviales, puede ser mejor hacerlo en la base de datos, con un find_by_sql y eso puede depender de la funcionalidad de fecha y hora de su base de datos, pero nuevamente almacenar los datos como un Tiempo también lo ayudará aquí. Por ejemplo, en Postgresql (que uso), obtener la semana de una clase es

date_trunc('week', starting_time)

que puede usar en una cláusula Group By, o como un valor para usar en alguna lógica de bucle en rails.

Re días de la semana, si necesita tener p. clases que cumplen 09: 00-10: 00 en MWF, entonces puede usar una tabla separada para los días en que se reúne una clase (codificada por ID de clase y DOW) o ser malvada (es decir, no normalizada) y mantener el equivalente de un matriz de DOW en cada clase. El argumento clásico es este:

  • La tabla separada se puede indexar de una manera para admitir selecciones orientadas a clases u orientadas a DOW, pero se necesita un poco más de pegamento para unir toda la imagen para una clase.
  • La matriz de DOW es más simple de visualizar para los programadores principiantes y un poco más simple de codificar, pero significa que razonar sobre DOW requiere mirar todas clases.

Si esto es solo para su horario personal de clases, haga lo que le dé el valor que está buscando y viva con las consecuencias; Si está tratando de construir un sistema real para múltiples usuarios, iría con una tabla separada. Todas esas reglas de normalización están ahí por una razón.

En cuanto a los nombres DOW (legibles para humanos), ese es un problema de la capa de presentación, y no debería estar en el concepto central de DOW. (¿Suponga que decidió mudarse a Montreal y necesita francés? Esa debería ser otra "cara" y no un cambio en la implementación central).

En cuanto a las horas de inicio / finalización, nuevamente el problema son sus requisitos. Si todas las clases comienzan y terminan en los límites de la hora (x: 00), ciertamente podría usar 0..23 como las horas del día. Pero entonces su vida sería miserable tan pronto como tuviera que acomodar ese seminario de 45 minutos. Como decía el viejo comercial, "Págame ahora o págame más tarde".

Un enfoque sería definir su propio concepto ClassTime y particionar todo el razonamiento sobre los tiempos para esa clase. Podría comenzar con una representación simplista (horas integrales 0..23, o minutos integrales después de la medianoche 0..1439) y luego '' crecer '' según sea necesario.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top