Modelado de un año, dia por dia.
 

Hola muchachos, vuelvo a este gran foro para hacerles una consulta de esas que solo ustedes pueden responder :P

Quisiera que me aconsejen en el correcto modelado de una base de datos.
El problema es el siguiente:
Tengo que modelar, digamoslo asi, un año entero ( o mejor dicho, varios ). Esto es necesario ya que para la mayoria de los dias del año ( los dias laborables ) empleados de una empresa asignarian la cantidad de horas que trabajaron ( obviamente esta cantidad es variable )
Obviamente una matriz no me parece muy correcto para una bd.
Yo tenia pensado hacer una tabla bieeeeennnn larga, que contenga los siguientes campos:
id_tabla( no lo pense mucho el nombre ), dia,mes,año,nro_empleado,horas
Dia,mes y año serian numeros obviamente, despues vere si hago tablas para ellos o si matcheo hacia nombres directamente en el codigo.
Lo que me hace sospechar, es que esta tabla se podria hacer extremadamente larga con el paso del tiempo, y no se si hay algun tipo de limite en bases de datos mysql para esto. Ademas tambien me gustaria que me aconsejen si esta solucion se puede tornar muy ineficiente con el pasar del tiempo ( es decir, a medida que avanzen los años, espero que tenga un rendimiento aceptable, y no que tarde mucho para hacer cada cosa el servidor )


Es la primer aplicación que voy a tratar de vender y es la primera que intento usar mysql(pero no es la primera que hago, ni es la primera en que uso bases de datos), asi que perdonen mi ignorancia.

Todavía no tengo nada hecho, asi que si me sugieren irme hacia otra bd diganmelo.


Gracias desde ya.

porque no utilizar un campo fecha en lugar de dia, mes y año, las horas las podrias desechar y usar el campo de horas, creo que esta bien la tabla porque aunque tendra muchos registros serian pocos campos

:confused::confused:

a ver... según yo, para saber cuantas horas trabajaron en un día, solo sería necesario guardar una fecha (completa, es decir, dias, mes, año y hora) de entrada y una fecha de salida. Es decir:


Tabla Horarios (o como quieras)
IDEmpleado (el tipo que prefieras), FechaEntrada (DateTime), FechaSalida (DateTime)


Para determinar cuantas horas trabajo solo se resta la fecha de salida menos la fecha de entrada...

:confused::confused:

Bueno, gracias por las respuestas.

Lo del campo unico de tipo fecha es buena idea.

Lo de la cantidad de horas que yo mencione, es solo por la manera en que estan acostumbrados, hasta ahora le dicen la cantidad de horas que trabajaron a alguno de los jefes. Aunque tambien les puedo ofrecer la opcion que dice ContraVeneno.

Pero bueno, quisiera que me aconsejen sobre la pregunta que hice sobre el largo de la tabla.

Leyendo un poco en el foro, encontre un topic similar en donde, como su bd consta de una sola tabla, les recomiendan usar SQLite.

Pero no tiene interfaz grafica, y lei por ahi que una de sus desventajas, al estar mas cerca del programa que una bd cliente-servidor, es que es mas susceptible a sus fallos. Asi que la verdad es que estoy entre mysql y access.

Hola Chompiras, Disgregar la fecha no es una opción muy recomendable. Lo mejor sería emplear un campo fecha.

Hay algo que no me queda totalmente claro: ¿Que relación hay entre los campos id_Tabla() y el campo id_Empleado(). Hay algo que no me queda muy en claro...

¿Estás tratando de establecer un calendario laboral en donde se registran las horas trabajadas en cada día?

Si la respuesta a esa pregunta, y por lo que pareciera ser el diseño de esa tabla, veo un grave problema de diseño.

Yo más bien veo tres tablas:
1. La tabla en donde están todas las personas
2. Una tabla en donde se registran los días hábiles
3. Una tabla intermedia en donde se registra las horas que dedica la persona a un día particular.

Este diseño visualmente sería un M-M:

Personas - 1 --- M - Asignaciones - M --- 1 - DiasLaborales

Con un diseño así se puede relacionar y asociar muchas asignaciones, a distintas personas. De igual modo, para una persona en particular, existe diferentes asignaciones de carga horaria para determinados días.

Por tanto como mínimo, para satisfacer tus requisitos se necesitan de los siguientes campos:

Tabla: Personas
--------------
IDPersona
Nombre
...

Tabla: DiasLaborales
-------------------
IDDiaLaboral
Fecha

Tabla: Asignaciones
------------------
IDAsignacion
FechaID -> FK (clave foránea) hacia DiasLaborales
IDPersona -> FK hacia Personas

¿Se entiende la idea?

Por el tema de la elección de la base de datos debes analizar aspectos técnicos, operativos, económicos, y hasta incluso legales. Súmese la experiencia en el uso de esta herramienta.

Saludos,

Sep.


Si la tabla de empleados la tenia en mente, por eso era lo de nro_empleado en vez de directamente nombre.

Me parecio barbara tu explicación, pero me quedo una duda, ¿en la tabla Asignaciones irian las horas trabajadas no?

Exactamente.
Me olvidé de escribir en la tabla el campo.

Saludos,

Ah joya entonces, me parece mejor tu diseño ya que en el mio almacenaba tantas veces cada dia laboral como empleados haya.