Portabilidad de SQL y conceptos clave de bases de datos

Enviado por Chuletator online y clasificado en Informática y Telecomunicaciones

Escrito el en español con un tamaño de 5,78 KB

EL MITO DE LA PORTABILIDAD

La existencia de un estándar SQL publicado ha generado algunas aseveraciones exageradas acerca de la portabilidad de SQL y sus aplicaciones. De hecho, las insuficiencias del estándar SQL-89 y las diferencias actuales entre los dialectos SQL son lo suficientemente significativas para que una aplicación deba ser siempre modificada cuando se traslada de una base de datos SQL a otra.

Limitaciones del estándar SQL-89 (SQL1)

1. Códigos de error:

el estándar SQL-89 no especifica los códigos de error a devolver cuando SQL detecta un error, y todas las implementaciones comerciales utilizan su propio conjunto de códigos de error. SQL2 especifica códigos de error estándar.

2. Tipos de datos:

el estándar SQL1 define un conjunto mínimo de tipos de datos, pero omite algunos de los tipos más populares y útiles, tales como las cadenas de caracteres de longitud variable, las fechas y horas y los datos monetarios. SQL2 afronta esto.

3. Tablas del sistema:

el estándar SQL1 no dice nada acerca de las tablas del sistema que proporcionan información referente de la estructura de la propia base de datos. Cada vendedor tiene su propia estructura para estas tablas. Las tablas se estandarizaron en SQL2.

4. SQL interactivo:

el estándar especifica el SQL de programa utilizado por un programa de aplicación, y no el SQL interactivo.

EL MITO DE LA PORTABILIDAD (continuación)

5. Interfaz de programa:

el estándar SQL1 especifica una técnica abstracta para utilizar SQL desde dentro de un programa de aplicaciones. Ningún producto SQL comercial utiliza esta técnica. SQL2 especifica una interfaz SQL embebida para lenguajes de programación populares, pero no interfaces a nivel de llamada.

6. SQL dinámico:

el estándar SQL1 no incluye las características requeridas para desarrollar frontales de bases de datos de propósito general, tales como herramientas de consulta y generadores de informes. SQL2 lo incluye.

7. Diferencias semánticas:

es posible ejecutar la misma consulta con dos implementaciones SQL diferentes, y producir resultados diferentes.

8. Secuencias de cotejo:

el estándar SQL1 no define la secuencia de cotejo (ordenación) de los caracteres almacenados en la base de datos. SQL2 incluye una especificación detallada.

9. Estructura de bases de datos:

los detalles del nombrado de la base de datos y de cómo se establece la conexión inicial varían enormemente y no son portables. SQL2 crea más uniformidad, pero no puede enmascarar completamente estos detalles.

CONDICIONES DE BÚSQUEDA

1. Test de comparación:

compara el valor de una expresión con el valor de otra.
   
Ejemplo: SELECT Nombre FROM RepVentas WHERE Contrato < '01-ENE-99'

2. Test de rango:

examina si el valor de una expresión cae dentro de un rango especificado de valores.
   Ejemplo: SELECT NumPedido, Importe FROM Pedidos WHERE Importe BETWEEN 2000.00 AND 2999.99

3. Test de pertenencia a conjunto:

comprueba si el valor de una expresión se corresponde con uno de un conjunto de valores.
   Ejemplo: SELECT Nombre, Cuota, Ventas FROM RepVenas WHERE OficinaRep IN (11, 13, 22)

4. Test de correspondencia con patrón:

comprueba si el valor de una columna que contiene datos de cadena de caracteres se corresponde a un patrón especificado.
   Ejemplo: SELECT Empresa, LimiteCredito FROM Clientes WHERE Empresa LIKE 'Arc%' AND Empresa NOT LIKE '_far%'

5. Test de valor nulo:

comprueba si una columna tiene un valor NULL.
   Ejemplo: SELECT Nombre FROM RepVentas WHERE OficinaRep IS NULL

Inconvenientes del manejo inadecuado de transacciones

Problema de la actualización perdida: se da cuando dos programas leen los mismos datos y utilizan los datos como base para un cálculo y luego tratan de actualizar los datos.

Problema de los datos no confirmados: se da cuando ocurre una actualización y la transacción es abortada.

Problema de los datos inconsistentes: se da con la consulta de datos con actualización confirmada posterior con otro usuario.

Problema de la inserción fantasma: se da con una consulta de BD y posterior inserción que afecta sobre la vista anterior.

Solución:

- El usuario no debe ver actualizaciones sin confirmación.

- Mantener transacciones breves.

- Liberar base de datos, utilizando COMMIT a menudo.

- Utilizar técnicas de cerramiento.

Restricciones para actualizar una vista

1. Restricción de unicidad:

obliga que los datos de una columna o combinación de columnas sean únicos en cada una de las filas de la tabla.

2. Restricción de clave primaria:

al igual que el de unicidad, pero también designa una columna o combinación de columnas como la clave de la fila, en el entorno de una relación padre/hija con otra tabla.

3. Restricción de clave foránea:

establece que el valor de una columna o combinación de columnas coincida con el valor de una clave primaria en alguna tabla padre.

DDL

Conjunto de sentencias SQL que permiten modificar la estructura de la BD

Sentencias:

 CREATE: para crear y definir un objeto de la BD
 DROP: para eliminar un objeto
 ALTER: para modificar la definición de un objeto

Entradas relacionadas: