Existen algunos puntos importantes a tratar cuando se desarrolla una aplicación para BBDD.
a) El modelo de datos (la BBDD)
b) componentes de acceso
a.1) Lo primero y principal las PK deben ser de tipo integer y siempre PK simples. Esto simplifica muchisimo a la BBDD gestionar las relaciones FK y por otro lado se elimina la redundancia de campos en las tablas foranea. (En muchos modelos me he encontrado con hasta 10 campos formando la PK) ¡eso es el infierno!, 10 campos arrastrados por todas las tablas FK.
Si puedes define lasa restricciones en la BBDD pues estas se ejecutan mucho más rapido que si las has de evaluar en la aplicación (ya que necesitaras ejecutar sentencias SQL) y las restricciones se ejecutan en la BBDD cuando se ejecuta alguna transacción de actualización.
No construir indices a diestro y siniestro, es preferible esperar y construirlos cuando los necesitemos para una SQL.
Para construir un indice debemos tener en cuenta los criterios restrictivos de más a menos. Quiero decir si tenemos una tabla que contiene los artículos que compra un cliente (idVenta, idCliente, idArtículo, FechaVenta, precio, etc) y se quiere obtener los artículos vendidos a un cliente en un periodo, el indice tendrá que ser compuesto, for por los campos mas restrictivos (idCliente, FechaVenta, Artículo). y los campos en la condición WHERE deberan estar en el mismo orden que los campos del Indice.
Para los gestores de bbdd a la hora de optimizar la sql les simplifica determinar que indices deben usar si lo ven claro en la clausula WHERE o INNER JOIN ... ON
a.2) Si es posible las relaciones entre tablas no sean del tipo (1 a null), no siempre puede ser, pero dentro de la medida de lo posible evitarlo. Los left-right join son muy pesados en las Query.
a.3) De ser posible el uso de triggers, SP, funciones, vistas, etc pues estos se gestionan en el servidor y no viajan por la red (es lo peor). Si tienes que hacer un proceso muy complejo de recuperación de datos, realiza este en un SP y obten en la consulta lo que necesites, de ese modo te quitas muchas lineas de programación.
a.4) Uso de secuenciadores para obtener una PK. Muchos programadores confunden el uso de estos con los contadores (de factura, de pedidos, etc) no tienen ningún relación a excepción de la semantica. Son atransacionales, lo que quiere decir que no pertenecen a ninguna transación. Hagamos un uso indiscriminado de ellos, para eso los pusieron. Con esto te evitas otro uso muy comun, ejecutar una consulta para obtener el valor más alto de una tabla o lo que es peor ejecutar constantes recordcount del dataset.
a.5) Si necesitas consultas muy repetitivas en tus programas, crea vistas, esto te ayudará a simplificar la cantidad de código que tienes que repetir en tu aplicación a nivel de sentencias SQL.
a.6) Si se han de actualizar datos en otras tablas tras una inserción, edición o borrado, crea triggers para dicho proceso. ¡No te haces a la ídea de lo que simplifica las aplicaciones y la agilidad que le dará a tu sistema!. Conozco mucha gente negada au uso de dichos eventos de las BBDD y el día que les surgio la necesidad de crear uno, no han dejado de darse con la cacerola en la testa por no haberlos usado anteriormente.
a.7) Y lo que más le pesa a una BBDD son las joins, pues ha de remover miles de registros para obtener el resultado que deseamos.
Una premisa importante para determinar si una consulta esta bien construida es conocer el número de registros que ha tenido que consultar para devolver Y.
Si Y supera el número de registros de la tabla principal de la SQL (mal) si se aproxima peligrosamente (mal), si ha tenido que consultar más registros de los que nos ha devuelto (mal), el gestor nos estrá indicando que nos falta un indice para obtimizar la consulta.
b.1)Muy importante que los componentes de acceso a datos sean bajo demanda. Esto quiere decir que solo se traen registros tal y como los vamos necesitando cuando se navega por los registros.
No usar nunca componentes del tipo TTable. Entonces será la muerte de la aplicación antes de empezar a manejar datos.
b.2) Determinar el tipo de transacción a manejar, dependiendo del tipo de acceso que se vaya a realizar. No es lo mismo una transacción para actualización de datos, que una transacción para una consulta o un listado.
b.3) Las transacciones para actualizar datos deben ser pequeñas es decir, no es nada recomendable usar un componente TIBDataSet para actualizar un registro o 10 registros, si para ello, al iniciar la transacción tuvo la BBDD que recuperar miles de registros. Por ello es recomendable usar transacciones distintas, una para consultas y otra para procesos de actualización. Algunos componetes como los FIBPlus permiten manejar este dos transacciones simultaneamente (Consulta y actualización).
b.4) Alejarnos dentro de lo posible de lanzar alegremente de SQL con todos los procesos. Aunque no guste mucho el estilo o la filosofia, hay que pensar que no estamos trabajando con ficheros de datos, las rejillas son muy pero que muy lentas, es preferible trabajar siempre con pantallas de consultas que filtren los datos. Las rejillas de datos son buenas para un detalle o para mostrar el resultado de una consulta. Pensemos que el usuario siempre va a buscar un dato o un conjunto de datos concretos, por lo que mostrar una rejilla sin haber sufrido un filtro previo no tiene sentido.
Lo que indico aquí tiene mucha más importancia, que si una BBDD es capaz de soportar miles de registros. Hoy en día es lo de menos, con los RDBMS actuales estamos en una Galaxia totalmente distinta. Los problemas de cueyos de botella se encuentra en los diseños de las BBDD y en como atacamos a los datos.
PD: Una SQL por compleja que sea, tarde más de 3 segundos en retornar los primeros datos es una consulta a replantear (esta mal planteada, faltan indices o lo que es peor, se crea un producto cartesiano).
