Desarrollo de Pruebas y Consultas SQL: Mejores Prácticas y Niveles de Aislamiento

Enviado por Programa Chuletas y clasificado en Informática y Telecomunicaciones

Escrito el en español con un tamaño de 8,28 KB

Tendencias en el Desarrollo de Pruebas

Desarrollo Basado en Pruebas (TDD)

  • TDD (Test Driven Development): Consiste en escribir las pruebas antes que el código.
  • Las pruebas deben comprobar una funcionalidad prevista.
  • Basado en la realización de pruebas unitarias.

Integración Continua

  • Integración continua: Integraciones automáticas frecuentes para detectar errores.

Modelos de Calidad para Pruebas

  • Inspirados en los modelos de madurez como CMMI.
  • TMM (Modelo de Madurez de Pruebas).
  • TMMi (TMM integrado): Utilizado en EEUU. Ofrece 5 niveles de madurez.
  • TPI (Proceso de Mejoramiento de Pruebas): Utilizado en Europa. Cercano a niveles de capacidad.

Consultas SQL

  • SELECT FROM: Consulta el valor de determinadas columnas de una tabla.
  • DISTINCT: Consulta solo los valores de las columnas especificadas de una tabla, cuyo valor no se repite.
  • WHERE: Consulta los campos de una columna que cumplan cierta condición.
  • ORDER BY: Consulta los campos especificados de una tabla, devolviendo el resultado ordenado.
  • UNION: Une el resultado de realizar varias consultas de selección.
  • INNER JOIN: Devuelve las filas cuando al menos existe una coincidencia en ambas tablas.
  • LEFT JOIN: Devuelve todas las filas de la tabla de la izquierda (nombre_tabla1), incluso cuando no coincide con la tabla de la derecha (nombre_tabla2). No se mostrarán las columnas de la derecha que no coincidan con las de la izquierda.
  • RIGHT JOIN: Devuelve todas las filas de la tabla de la derecha (nombre_tabla2), incluso cuando no coincide con la tabla de la izquierda (nombre_tabla1). No se mostrarán las columnas de la izquierda que no coincidan con las de la derecha.
  • FULL JOIN: Devuelve todas las filas de las dos tablas.
  • SELECT…INTO: Se utiliza para crear copias de seguridad (backup) de las tablas.
  • BETWEEN: Se utiliza en la condición de las consultas de selección con la cláusula WHERE para seleccionar solo aquellos campos que estén dentro de un rango de valores.
  • IN: El operador IN se utiliza en la condición de las consultas de selección con la cláusula WHERE. Este operador hace que la consulta devuelva el resultado solo si la columna especificada en la condición toma un valor de los múltiples valores especificados con el operador IN.
  • TOP: Especifica el número de filas que debe devolver una consulta.
  • ALIAS: Son nombres abreviados que se le pueden asignar a columnas o tablas para utilizarlos dentro de la misma consulta.
  • LIKE: Este operador se utiliza para buscar determinados patrones en las columnas especificadas en una tabla.
  • PATRONES: Se utilizan para sustituir uno o más caracteres cuando realizamos búsquedas dentro de la base de datos. Es decir, que se utilizan cuando queremos que una consulta nos devuelva solo ciertas filas en las que el valor que toma un campo de una columna cumpla una cierta estructura.
    • %: Sustituye a 0 o más caracteres.
    • _: Sustituye un carácter.

Utilización del Conjunto Resultado

  • Una vez ejecutadas las sentencias en la base de datos, necesitamos obtener la información resultante.
  • En JSP, la información se almacena en una estructura llamada ResultSet:
    • Almacena todos los registros o filas resultantes de la ejecución de una sentencia SQL.
    • Proporciona acceso a los datos de dichos registros a partir de una serie de métodos: getDouble(), getFloat(), getString(), getInt(), next(), etc.
    • Contiene un puntero que señala al registro actual y que lo utiliza para acceder al resto de registros que almacena.
  • En PHP existen métodos para recorrer la estructura que devuelve la ejecución de una sentencia SQL.
    • Destacar los siguientes: mysql_fetch_row(), mysql_fetch_array(), mysql_result() y mysql_free_result().
  • En ASP, la información se almacena en una estructura llamada RecordSet:
    • Se comporta igual que la estructura ResultSet de JSP.
    • Los métodos más utilizados son: EOF, MoveNext, MoveFirst, MovePrevious y MoveLast.

Transacciones

  • Son un conjunto de instrucciones que se ejecutan de manera atómica, es decir, como si fuera una sola instrucción o sentencia SQL.
  • Deben cumplir las siguientes propiedades del test ACID:
    • Atomicidad: El grupo de sentencias debe comportarse como un “todo o ninguno”. Si alguna de ellas no se pudiera ejecutar, se debería poder deshacer o revertir.
    • Consistencia: La base de datos debe quedarse en un estado consistente y coherente al finalizar la transacción.
    • Aislamiento: Los datos modificados durante una transacción no deben ser visibles para otros usuarios hasta que esta no finalice y se hayan realizado todos los cambios de manera definitiva.
    • Permanencia: Los efectos de una transacción se almacenarán de forma permanente.
  • Existen dos formas de finalizar una transacción:
    • Commit: Finaliza la transacción de forma exitosa y hace permanentes los cambios realizados.
    • Rollback: Aborta la transacción porque alguna de las instrucciones que la componen se ha ejecutado y ha fallado. Esta instrucción deshace todos los cambios temporales que se pudieran haber hecho en la base de datos.

Serialización y Niveles de Aislamiento

Problemas

  • Lectura sucia (Dirty Read): Esta situación se da cuando una transacción T1 modifica los datos que lee T2, y luego se hace un rollback de T1. Por lo tanto, T2 ha leído unos datos que no existen.
  • Lectura no repetible (Non-Repeatable Read): En una transacción T1 queremos leer dos veces los mismos datos, pero entre ambas lecturas T2 elimina algunos datos. Esto provoca que tengamos resultados distintos en cada una de las lecturas, ya que en la segunda lectura nos faltarán datos con respecto a la lectura anterior.
  • Lectura fantasma (Phantom Read): Es parecida a la anterior, ya que en una transacción T1 queremos leer dos veces los mismos datos, pero entre ambas lecturas T2, en vez de eliminar, añade algunos datos. Esto provoca que al leer por segunda vez nos encontremos tuplas que anteriormente no existían.

Solución: Niveles de Aislamiento

  • Serializable: Si aplicamos el nivel serializable, podremos ver la base de datos antes o después de la ejecución de una transacción, pero nunca mientras se está realizando. Por lo tanto, da la sensación de que las instrucciones se ejecutan una detrás de otra. Esto solo es aplicable al usuario que lo elige, es decir, que otro usuario puede tener definido otro nivel de aislamiento. Este es el nivel que viene por defecto en las bases de datos.
  • Read Committed: Este nivel evita la lectura sucia, permitiendo solo la lectura de los datos que han sido confirmados mediante la realización de un commit de otra transacción.
  • Repeatable Read: Este nivel, en cambio, evita la lectura no repetible. Es igual que “Read committed”, añadiéndole la restricción de que todo lo que veamos en una lectura inicial de una transacción debemos poder verlo en lecturas posteriores.
  • Read Uncommitted: Si una transacción se ejecuta con este nivel de aislamiento, puede ver las modificaciones realizadas por otra transacción, sean actualizaciones, borrados o inserciones, a pesar de no haber hecho un commit.

Entradas relacionadas: