Ir al contenido principal

17. Inicio del desarrollo del trigger y primeros problemas técnicos

Día: 25/05/2023

Desde: 10:10 am / Hasta: 12:24 pm

Tiempo transcurrido: 2 horas 14 minutos

Los triggers son una parte esencial de cualquier sistema de base de datos, ya que entendimos cómo permiten realizar acciones automáticas en respuesta a ciertos eventos en la base de datos. En este caso, el equipo necesitaba desarrollar un trigger que respondiera a los eventos de login de los usuarios o por otro lado aplicarlo a la nueva implementación del proyecto, las Nuevas Tarjetas.


Inicialmente se diseñó la idea del trigger utilizado en la autenticación de los usuarios, se decidió que el trigger debería verificar si el nombre de usuario y la contraseña ingresados por el usuario son válidos y, en caso de serlo, determinar si el usuario es un administrador o un tarjetahabiente. Este proceso requería una cuidadosa planificación y diseño, ya que cualquier error en esta etapa podría tener graves consecuencias para la seguridad y la funcionalidad del sistema.


A medida que el equipo comenzó a implementar el trigger, se encontraron con varios problemas técnicos. En particular, tuvieron dificultades para configurar el trigger para que respondiera correctamente a los eventos de login. Pero después de replantearse la funcionalidad que tenía este trigger decidimos usar la otra idea que era relacionada con las nuevas tarjetas. Comenzamos a dirigir los esfuerzos para ir desarrollando esa parte.

Comentarios

Entradas populares de este blog

5. Trabajo en el demo - Actualización del connection string

Día: 20/02/2023 Desde:  9:20 pm / Hasta: 10:38 pm Tiempo transcurrido: 1 hora 18 minutos En este avance decidimos seguir con el desarrollo del Demo, recordando que el Demo nos estaba generando problema con respecto a la autenticación. Cambiamos el connection string y al comprobar en la interfaz ya no estaba dando ese problema continuamos con el siguiente elemento. Procedimos a hacer esa misma conexión pero con las entradas de texto para poder insertar nuevos elementos en la tabla principal y ya esta vez tuvimos éxito a la primera ya que habíamos superado el problema de la autenticación. El gran problema con esta forma de programar el Demo es que infringía en las reglas propuestas por el profesor en clase, relacionadas con el SQL incrustado en capa lógica, por lo que esto se resolvería con stored procedures más adelante cuando ya programáramos la base de datos e interfaz correspondientes al proyecto. Aún en este punto nos costó la parte de introducir los datos tomados de un textbox ...

17. Optimización y documentación del código SQL en la tarea programada

Día: 05/04/2023 Desde: 9:18 am / Hasta: 11:18 pm Tiempo transcurrido: 2 horas Durante esta tarea programada, uno de nuestros objetivos fue revisar el código de los procedimientos almacenados existentes para asegurarnos de que estaba funcionando correctamente. Para ello, revisamos cuidadosamente cada sección del código para identificar cualquier problema o error. Una vez que identificamos los problemas, agregamos comentarios claros en el código para explicar el funcionamiento de cada sección y asegurarnos de que otros miembros del equipo pudieran entender el código con facilidad. Los comentarios ayudaron a hacer que el código fuera más legible y fácil de mantener, lo que es fundamental para proyectos en equipo. Además, encontramos algunos errores menores en la sintaxis del código y los corregimos de manera inmediata. Esto incluyó la eliminación de espacios en blanco innecesarios y la corrección de errores de ortografía. Aunque estos errores parecían pequeños, podían tener un impacto sig...

4. Inicio del desarrollo del script de llenado de catálogos

Día: 04/05/2023 Desde: 1:10 pm / Hasta: 3:36 pm Tiempo transcurrido: 2 horas 26 minutos Con la estructura de la base de datos establecida, el equipo se centró en el desarrollo del script de llenado de catálogos. Este script sería responsable de poblar las tablas de la base de datos con datos iniciales para su funcionamiento. El equipo decidió que el script debería ser flexible y fácil de modificar, para permitir cambios en los datos a medida que el proyecto avanzara. Se discutieron diferentes enfoques para la implementación del script, y se decidió utilizar procedimientos almacenados para maximizar la eficiencia y la seguridad. Sin embargo, la tarea no estuvo exenta de desafíos. La definición de los datos iniciales requería una comprensión clara de las reglas de negocio y de las necesidades de los usuarios finales.