Cita: Hasta ahora había estado manejando diseños de bases con tablas relacionales sin problemas . . .
Con datos que rara vez eran modificados, y de los cuales podíamos ver un historial íntegro . . .
En otras palabras, tenías un esquema de base de datos sin demasiadas incidencias, que solamente tendría alguna que otra tabla de actualización constante (sesiones, por ejemplo).
Cita: Una base . . . la cual sufrirá modificaciones diarias en la tabla de usuarios . . . afectando otras tablas claro está . . .
Ésto no es problema alguno . . . hasta el punto en que quieren consultar por fecha . . .
En x fecha, éste usuario tenía tales características, generando x reportes.
En y fecha, el mismo usuario tenía otras características, generando y reportes.
Eso no representa
ningún problema. Lo único que hace es requerir una
normalización de la tabla. Nada más.
Sin un usuario tiene atributos que
pueden variar en el tiempo, eso implica que hay un conjunto de atributos hoy
asignados a USUARIO y
que en realidad pertenecen a otra tabla. Esa tabla, a su vez debe contar con otros atributos que le den entidad a la existencia de la misma, y por lo que describes esos atributos tiene que ver con el
período de vigencia de la información.
Así, si la dirección del usuario fuese importante
y modificable, hay que establecer una tabla DIRECCION_USUARIO que contenga los atributos de la dirección del usuario durante un período de tiempo determinado (userid, fecha_inicio y fecha_fin como determinantes).
¿Se comprende la idea?
Lo que deberías hacer es describirnos más en detalle la estructura de las tablas a modificar y cuáles son las modificaciones que se producirían por el nuevo INPUT del sistema.
Pero la cosa no parece ser demasiado complicada, por lo que describes. Como dije, parecen problemas de
normalización...
Cita: Porque había pensado que los datos que sifrirán mas modificaciones puedo mandarlos a otra tabla "MovimientosDeUsuarios"
Mala idea. Estarías probablemente poniendo redundancia de datos. Lo que tienes que establecer es cuáles atributos serían constantes, cuales opcionales y cuáles variantes.
Así, un dato constante es el userid o username, otros el nombre y apellido del usuario, su sexo, nacionalidad, estudios, profesión, etc. En ciertos contextos la dirección es opcional, como el teléfono o el e-Mail. En otros casos no, y según establezcas cuáles son los campos variantes y cuáles de ellos opcionales, sabrás qué datos son los que realmente deberás derivar a otra tabla.
Supongamos el caso de la dirección. Si consideras variante la dirección, eso puede que implique considerar variante un teléfono fijo (según el país), pero no un celular. ASí en ese caso puede que el fijo se deba derivar a otra tabla, mientras que el celular puede dejarse en la tala primaria y la dirección a una tercera tabla.
Resumiendo:
1) Postea las estructuras de las tablas.
2) Describe qué tipo de influencia tiene el nuevo input del sistema.
3) Repasa normalización y vuelve a analizar el sistema. Propone los cambios y vemos.