Bases de datos (3ra parte)

En el pasado post escribí acerca de la importancia de una buena estructura en una base de datos, así que hoy toca escribir acerca de dicha estructura pero para protegernos de un posible un tanto común pero con escasa información de como resolverlo.

A este error le llamo "Ruptura de interrelación" y se origina cuando en un par de tablas relacionadas, a través del primary key, para accesar a los campos de una de otra se elimina un registro. Un ejemplo sería el siguiente, donde la tabla notas se interrelaciona con la tabla usuarios:

Tabla1: usuarios
Campos: id, nombre, edad
Fila1: 1, juan, 15
Fila2: 2, pedro, 20

Tabla 2: notas
Campos: id, id_usuario, nota
Fila1: 1, 2, hola
Fila2: 2, 1, como

La consulta de selección (select query) empleado para este ejemplo es (ansi):

SELECT DISTINCT notas.id, usuarios.nombre, usuarios.edad, notas.nota FROM notas, usuarios WHERE notas.id_usuario=usuarios.id

Con esta consulta el resultado sería:

1, pedro, 20, hola
2, juan, 15, como

Pero que pasaría sí se eliminara el registro 1 de la tabla usuarios con una consulta como:

DELETE FROM usuarios WHERE id=1

Al volver a ejecutar la consulta de selección sólo retornaría un resultado, siendo éste:

1, pedro, 20, hola

Ésto sucede por el error que denominé "Ruptura de interrelación" porque en la consulta sólo se seleccionan los registros cuyo campo notas.id_usuario = usuario.id ignorando aquellos que son notas.usuario = null.

Hay varias soluciones:

1.- Usar una cláusula como ésta: WHERE (notas.id_usuario=usuario.id OR notas.usarios=NULL).
2.- Usar los equivalentes a cada lenguaje sql de IF NOT EXISTS(usuario.id, 'algo',usuario.nombre)

Otra opción más es hacer uso de triggers y funciones para cambiar el campo notas.id_usuario a 0 cuando dicho id de usuario es eliminado y luego usar consultas como IF(notas.id_usuario=0, 'sinregistro', usuario.nombre).

En fin, como podrán leer existen varias formas, aparte de las mencionadas (como el if not null), para evitar esas rupturas de interrelación que pueden finalizar en registros innaccesibles por consultas de selección como la primera expuesta.

Así que les recomiendo por mucho que lean a fondo los manuales de consultas selección, triggers, funciones y reserved keywords propias del sql que esten usando.

Base de datos (2da parte)

Anteriormente ya hablé (escribí) de las bases de datos y su importancia en todo tipo de aplicaciones. Pero ahora toca el turno de las estructuras de éstas bases de datos.

La estructura de una base de datos es igual de importante que el código que usemos para leerla y insertarle datos (independientemente del lenguaje de programación usado). De ella dependerá que nuestra aplicación sea adaptable a futuras versiones sin mayores actualizaciones.

Un ejemplo de ello sería una aplicación de ventas donde podemos controlar el inventario en una tabla de nuestra base de datos. Pero también podemos ver quien realizó la compra. En un futura actualización podriamos incluir quien realizó la venta a través de un campo llamado (siguiendo el ejemplo) "vendedor_id".

Así que si van a usar una bse de datos en su aplicación les recomiendo que creen tantos campos como sean necesarios más los que de momento podrían no serlo, ya que en un futuro podríamos llegar a usarlos.

Un buen programa y su base de datos

Refiriéndonos a programas de administración de contenido, talleres, ptv, etc., se debe ser conciente que una de las características con la cual deben contar dichos programas es con la capacidad de ser adaptable a las necesidades de cada quien.

Me es muy frecuente ver códigos o programas limitados en ese rugro ya que no se pueden agregar datos, categorías, etc. a placer. Así que uno de los consejos para programar sería definitivamente el uso de algún motor de bases de datos (sqlite, access, etc.) siempre estructurándola de una forma eficiente.

Es precisamente en las bases de datos donde reside la adaptabilidad, parte de la velocidad de procesamiento (otra parte en las consultas sql correctas) entre otros beneficios. La clave esta en una buena estructura en la interrelación y dependencia entre tablas.

Uno de los errores más comunes es creer que con un par de tablas en la base datos bastaría para poder almacenar todo lo que queremos, pero es precisamente ahí donde se pueden generar sobresaturaciones que resulten en la ralentización del retorno de datos. Ya con una buena estrutura solo resta obtener los datos mediante consultas sql un tanto complejas que permitan disminuir el número de éstas.

Si se usan bases de datos online es importante preservar la seguridad de los datos como nombre de usuario, password, etc. ya que nunca se esta exento de un ataque a la misma.

Un ejemplo claro de adaptibilidad de contenidos, permisos y otras funciones compartidas, son los sistemas de foros como vbulletin y phpbb, por mencionar algunos, junto con sus deficiencias mencionadas en publicaciones anteriores.

Por ahora estoy desarrollando una aplicación, que luego trasladare a php, para la administración de contenidos educativos así que "stay tuned".

Búsquedas concatenadas en SQLite3

La forma habitual de buscar 1 parámetro en más de 2 campos de una tabla sería por ejemplo:

[code]SELECT * FROM tabla WHERE campo1='parametro' OR campo2='parametro'[/code]

Pero hoy les muestro como hacer una búsqueda concatenada para un mismo parámetro.

Primero comenzaré recordando la forma de concatenar (unir) campos en una consulta. Para concatenar 2 o más campos deben usar este doble signo ||. Ejemplo:

[code]SELECT nombre||apellido FROM tabla[/code]

Esto nos arrojaría un resultado como RamónPérez (noten que no hay espacio entre el apellido y el nombre).

Así que para dejar el espacio entre ambos campos debemos concatenarlo (sin olvidar las tildes):

[code]SELECT nombre||' '||apellido FROM tabla[/code]

Estos nos arrojaría un resultado como Ramón Pérez (noten que el espacio ahora si aparece). Podemos poner lo que sea dentro de ' ' y crear concatenaciones mejores, como por ejemplo: ||'Nombre: '||nombre||' Apellido: '||apellido

Bueno, pues es similar para cuando queremos concatenar campos posterior a la cláusula WHERE en una consulta de selección. Ejemplo:

[code]SELECT * FROM tabla WHERE nombre||apellido='Alonso'[/code]

En esta consulta en lugar de hacer algo como "select * from tabla where nombre='alonso' or apellido='alonso'" estamos concatenando el campo de búsqueda (nombre||apellido). Esto nos ahorra líneas de código y ya en usos un poco más complejos podemos realizar consultas en campos multiples campos keywords con simples scripts.

Espero les agrade esa pequeña info de sqlite.

Una buena estructura de base de datos

El tener una buena estructura en nuestra base de datos es imprescindible no sólo por orden, sino también para reducir el peso de la misma así como poder brindar mejores reportes (con más detalles autocalculables por ejemplo). Ah, y la rápidez con que se hagan las consultas también dependerá de ello.

Aunque el tener una sola tabla donde acumular ciertos registros que luego puedan ser agrupados para mostrar resumenes o concentrados de la misma puede llegar a ser tentador, no en todos los casos es viable.

Un ejemplo sería el sólo contar con una tabla para registros de facturas donde se ingresan todos los artículos de dicha factura y cuando se quiere ver en forma de concentrado (por folio) sólo se agrupasen los registros. El error en este tipo de tablas y usos es que pueden llegarse a repetir datos en ciertos campos de forma innecesaria (como el número de folio, nombre del cliente, RFC, etc.), provocando el incremento en el peso de nuestra base de datos.

Una solución a esto es contar con 2 tablas interrelacionadas donde la primera sólo sea un control del ID de la factura con detalles como folio, fecha, cliente, RFC, etc. Y la segunda tabla con los registros de los artículos y precios de los mismos.

De esta forma evitamos repetir los datos de RFC, cliente, fecha y otros, en el registro de cada artículo que constituye la factura. Esto sin mencionar que a veces se usa un campo para comentarios que suelen extenderse bastante.

Un consejo es que recuerden que múltiples tablas pueden accederse en una sola consulta mendiante el uso de left join, full join o consultas en formato ANSI. Por ello a veces es necesario manejar más de un índice único para cada registro en nuestras tablas.