none
Como hacer un cierre de año en un sistema VB.net SQL RRS feed

  • Pregunta

  • Buenas tardes, he visto en sistemas que hacen al finalizar el año cierra todo y para el siguiente año carga nose si la base de datos vacia o que pero solo se ve el nuevo año. Como hacer eso y cuando necesite buscar informacion del año pasado cargar  nuevamente la bd de ese año pero sin que afecte el trabajo  de otro porque hay sistemas que al hacer eso los demas paran la operacion y nadie puede ingresar..

    Quisiera por favor ejemplos que hacer como hacer seria interesante aprender eso ya que mis proyectos ninguno tiene eso pero se que debo tener.

    Saludos y Gracias

    lunes, 9 de abril de 2018 22:40

Respuestas

  • Bueno, sí, podrías añadir otra base de datos con el mismo esquema y vacía. Desde código cliente simplemente enviarías de nuevo a ejecutar el mismo script que se utilizó para crear la base de datos original en primer lugar, después de haber renombrado ésta. Los Logins no cambian, los Users y sus permisos habría que volverlos a crear en la nueva base de datos, salvo que en SQL uses Roles de Aplicación y en consecuencia todos los usuarios y permisos se controlen desde el lado de la aplicación.

    Pero no debería ser necesario. Aunque a 31 de diciembre la base está muy cargada, no debería ser motivo para que se vuelva lenta ni para que haga mal los cálculos, esto indicaría un error de diseño o de configuración o de programación. Si los datos están bien indexados por el campo de fecha y todas las consultas filtran por este campo, el crecimiento de los tiempos de acceso es logarítmico con la ocupación de la base de datos, son lo que puede crecer muchísimo el tamaño mientras que el crecimiento de los tiempos de acceso es muy pequeño. Si aún así ese pequeño crecimiento se considerase inaceptable, se puede evitar aplicando particionamiento de tablas. La ventaja de esto (frente a mover los datos a otra base de datos) es que si lo necesitas puedes enviar una consulta que abarque fechas de años anteriores, cosa que no es igual de fácil si los datos están en varias bases de datos.

    • Marcado como respuesta Javier Roque miércoles, 11 de abril de 2018 22:51
    miércoles, 11 de abril de 2018 6:32

Todas las respuestas

  • Una forma de hacerlo es agregar en las tablas en las que sea oportuno un campo "fecha", y luego en la capa de datos asegurarse de que todas las consultas a base de datos van condicionadas por la fecha del ejercicio actual (y lógicamente aquellas partes en las que permitas consultar otro ejercicio tienen métodos en la capa de datos para permitirte especificar la fecha en lugar de forzar la actual).

    Acuérdate de condicionar por "desde fecha...hasta fecha" en lugar de solo por el año, por si acaso alguna vez tienes que ejecutar el programa en alguno de los sitios en que los ejercicios fiscales no coinciden con el año natural.

    martes, 10 de abril de 2018 12:25
  • Respecto a lo que me dices es de sistema contable? porque lo menciono en sistemas normales inventarios y otro tipo de sistemas. Se sabe que al llegar dic 31 del 2018 la base de datos estara  muy copada en peso claro, con el tiempo se pondria lento el sistema supongo lo he visto en algunos sistemas en una empresa y comienza a fallar los calculos y no dan valores exactos, es por ello que pregunto si hay forma de llegar al 31 dic y que cargue una base de datos con la misma estructura de sus tablas sin tocar los usuarios del sistema y el resto vacio y emepzar a trabajar el año 2019 es posible eso? tengo que hacer algun formulario aparte donde escoger o validar eso? o todo es desde sql?

    Gracias

    martes, 10 de abril de 2018 21:53
  • Bueno, sí, podrías añadir otra base de datos con el mismo esquema y vacía. Desde código cliente simplemente enviarías de nuevo a ejecutar el mismo script que se utilizó para crear la base de datos original en primer lugar, después de haber renombrado ésta. Los Logins no cambian, los Users y sus permisos habría que volverlos a crear en la nueva base de datos, salvo que en SQL uses Roles de Aplicación y en consecuencia todos los usuarios y permisos se controlen desde el lado de la aplicación.

    Pero no debería ser necesario. Aunque a 31 de diciembre la base está muy cargada, no debería ser motivo para que se vuelva lenta ni para que haga mal los cálculos, esto indicaría un error de diseño o de configuración o de programación. Si los datos están bien indexados por el campo de fecha y todas las consultas filtran por este campo, el crecimiento de los tiempos de acceso es logarítmico con la ocupación de la base de datos, son lo que puede crecer muchísimo el tamaño mientras que el crecimiento de los tiempos de acceso es muy pequeño. Si aún así ese pequeño crecimiento se considerase inaceptable, se puede evitar aplicando particionamiento de tablas. La ventaja de esto (frente a mover los datos a otra base de datos) es que si lo necesitas puedes enviar una consulta que abarque fechas de años anteriores, cosa que no es igual de fácil si los datos están en varias bases de datos.

    • Marcado como respuesta Javier Roque miércoles, 11 de abril de 2018 22:51
    miércoles, 11 de abril de 2018 6:32
  • Chevere me da ya una idea pero lo del scrip de la bd no se me ocurrido muchas gracias.

    Respecto a cuando la bd se pone lenta a mi en lo personal no me a pasado pero en una empresa lo vi y pasaba eso entonces tenian que vaciar la bd y esto comenzaba a mejorar entonces me pongo a pensar me vaya a suceder algo similar estoy solo proyectandome.

    Bueno Gracias x tu respuesta.

    miércoles, 11 de abril de 2018 22:51
  • [...] cuando la bd se pone lenta [...] en una empresa lo vi y pasaba eso

    Cuando pasa eso, normalmente indica un defecto de indexación en la base de datos. Se están transmitiendo consultas cuyo plan de ejecución no permite resolverlas utilizando los índices, y el sistema se ve obligado a realizar un barrido completo de tabla (table scan o clustered index scan). Ese tipo de barridos, efectivamente se vuelve lento cuando la tabla tiene muchos datos. Es responsabilidad del desarrollador cerciorarse de que las consultas están bien construidas y pueden resolverse eficientemente usando index seek. Y es responsabilidad del DBA cerciorarse de que existe un buen plan de mantenimiento para que los statistics se mantengan al día, al igual que los planes de ejecución cacheados y la defragmentación de la base de datos. 
    jueves, 12 de abril de 2018 6:10