2011-06-15 8 views
9

Recientemente he adoptado un proyecto con un modelo Employee que debe contener las horas disponibles de la persona como un atributo.Representación de períodos de tiempo en la IU y la base de datos

El formulario existente usa 168 casillas de verificación para representar cada hora de la semana y almacena la información como siete cadenas binarias de 24 bits en la base de datos, cada bit actúa como booleano verdadero o falso para su hora correspondiente de ese día.

Realmente me gustaría hacer la transición a algo un poco más elegante y manejable, pero no he podido encontrar soluciones simples que coincidan con la flexibilidad de la implementación existente.

Almacenar periodos de tiempo como inicio y finalización puede ser tan tedioso como la entrada cuando puede haber múltiples por día, y probablemente haría que consultar la disponibilidad en un momento particular sea más complicado.

¿Existe una mejor práctica para manejar este tipo de información, tanto en la interfaz de usuario como en la estructura de la base de datos?

+0

PostgreSQL admite nativamente los intervalos de tiempo como un tipo de datos. – Pointy

+0

Eso definitivamente es bueno saberlo, pero no estoy seguro de que realmente resuelva el problema. Si no me equivoco, esos intervalos no están vinculados a una hora de inicio o finalización específica, por lo que tendrían que usarse como parte de una estructura de datos más compleja para representar toda la información requerida. Creo que lo que realmente estoy buscando es una manera limpia y manejable de ingresar, almacenar y consultar 168 booleanos. O una mejor forma de representar cada hora de la semana. – Luke

+0

Bueno, podría emparejar un campo de intervalo con un campo de fecha, de modo que el campo de fecha daría la hora de inicio y el intervalo de la duración. No sé si eso sería mejor o peor que solo dos campos de fecha; dependería de la semántica y las consultas que te gustaría ejecutar. – Pointy

Respuesta

1

Me gustaría modelar los datos en la base de datos de esta manera.

Employee/Day/Hour Relationship

Hay una relación muchos a muchos entre los empleados y horas para cada día de la semana.

En el lado de la interfaz de usuario, puede utilizar las casillas de verificación de los días y los cuadros de lista de selección múltiple para establecer las horas de un día determinado.

+0

Este parece el enfoque más prometedor hasta ahora. Inicialmente dudaba sobre el modelo de los días de la semana y los números del 0 al 23, pero realmente permite una manera mucho más sencilla de consultar la disponibilidad. – Luke

+0

Pensándolo bien, ¿existe la ventaja de extraer horas y días a sus propias mesas de esta manera? ¿Por qué no puedes reemplazar 'hour_id' y' day_id' con un entero 'hour' y una cadena' day'? Con la validación adecuada, nunca deberían tener un valor inesperado, y no creo que esto aleje la flexibilidad del enfoque. – Luke

+1

Lo hice para modelar una normalización adecuada. Si alguna vez necesitó almacenar descripciones adicionales sobre las horas y días, habría espacio para almacenarla. Por ejemplo, la tabla DOW podría tener un int representando el día numérico, un Short_Day con lunes, martes, miércoles, etc. y un Long_Day con lunes, martes, miércoles, etc. La hora puede tener la hora int, luego un char con 12 am, 1 am, etc. o 12-1am, 1-2am, etc. Esto ayudaría a su interfaz al proporcionar una variedad de descriptores para la legibilidad humana. –

1

¿Podría simplemente hacer bloques de período de tiempo?

Employee 
    Availability 
    7AM -> 12PM 
     Monday 
     Tuesday 
     Wednesday 
    1PM -> 4PM 
     Monday 
     Tuesday 
    1PM -> 5PM 
     Wednesday 

Cada usuario tiene una lista de bloques de tiempo que representan una o más horas durante el día. Cada bloque de tiempo también podría representar uno o más días de la semana. Dependiendo de cuán compleja sea la disponibilidad de los usuarios, podría haber muy pocos datos o mucho.

La interfaz de usuario no tendría que cambiar realmente si no lo deseaba, ya que podría averiguar qué casillas de verificación están marcadas y construir un bloque de período de tiempo. Si hay una brecha de una o más horas entre horas, simplemente se convertiría en otro período de tiempo.

Adición de cambio de interfaz de usuario :: http://imm.io/6vGk

Viendo turnos de los empleados :: http://imm.io/6vGv

+0

Entonces, en este caso, ¿habría una tabla de disponibilidades separada que tuviera las columnas 'start hour',' end hour', 'day', y' user_id'? Eso podría hacer que la base de datos sea un poco más fácil de observar, pero no estoy convencido de que haría las entradas o las consultas más fáciles. – Luke

+0

Sí, eso podría funcionar para la base de datos. En cuanto a las consultas, solo depende del tipo que necesite hacer, cuanto más compleja sea la consulta más difícil será. La IU puede ser lo que quieras realmente ... por ejemplo, agregaré algunas imágenes a mi respuesta anterior sobre lo que hice para agregar/mostrar turnos – CraigW

0

Almacenamos horarios de los empleados y las horas no disponibles en dos tablas diferentes. La búsqueda está generando horas disponibles y luego excluye no disponible. La estructura de datos para los horarios de los empleados es bastante complicada, ya que el almacenamiento de la programación para cada día acaba de hacer que nuestra búsqueda sea muy lenta y las tablas sean grandes.

Cuestiones relacionadas