Hola de nuevo Rolando:
Te comento lo siguiente:
Esto no necesariamente es cierto, me explico. Cuando hablamos del concepto de "velocidad" hay variables que no debemos perder de vista, como el tamaño de las tablas, el tipo de campos que son llaves, el número de tablas que están involucrados, el tipo de condiciones que estás armando en tu condición etc.
TODOS los DBMS's tienen algoritmos optimizados para el uso de índices y llaves, esto implicaría entonces que cualquier consulta en donde se involucren llaves e índices "deberá" ser más rápida que una que no lo sea. ¿Cierto?... En la mayoría de los casos podría asegurar que sí, es más, hablando de lo que preguntabas en tu primer pregunta, en la práctica es más rápido hacer JOIN's que hacer uniones explicitas, es decir:
es mejor poner esto
que hacer esto:
y cuando te digo que es cierto, es cierto... igual con MySQL estás diferencias no son perceptibles, pero he tenido la oportunidad de trabajar con otras BD's como PostgreSQL, SQL Server, Firebird, Oracle, etc. y en algunos casos las diferencias pueden ser incluso de varios minutos (podrás imaginarte entonces el tamaño de nuestras consultas :S)
Insisto, cuando hablamos de pocas tablas o pocos registros, las diferencias pueden ser insignificantes, pero cuando hablamos de volumen pueden ser considerables. Entonces, si esto es verdad ¿deberíamos utilizar siempre los indices y las llaves foráneas? no necesariamente... (diablos, me estoy contradiciendo entonces o_O)
En algunos casos por ejemplo, cuando hablas de millones de registros colocar un indice puede resultar no tan benéfico. El uso por ejemplo de campos tipo VARCHAR en lugar de campos numéricos TAMBIÉN AFECTA EL TIEMPO DE RESPUESTA, sin que esto tenga necesariamente qué ver con que sean indices o llaves. Cuando se hacen BULK INSERT's o inserciones masivas, tampoco es recomendable utilizar campos llaves o indices, pues hace el proceso más lento...
Ahora bien, también comentas esto:
Creo que no ha quedado claro, que si lo haces desde la BD's NO TIENES QUE PROGRAMAR NADA ADICIONAL, Si defines una llave foránea TU NO PROGRAMAS UN TRIGGER QUE HAGA LA ELIMINACIÓN... esto lo hace la BD's de manera automática.
Mucho ojo, el que puedas hacer una acción de BD's desde un lenguaje de programación NO IMPLICA QUE DEBAS HACERLO O SEA LO MEJOR.
Efectivamente, coincido contigo en que puedes implementar mediante cualquier lenguaje de programación el proceso de eliminación en cascada, indicando un evento para cualquier objeto, pero te apuesto mi desayuno a que este SIEMPRE SERÁ MAS LENTO QUE HACERLO DIRECTAMENTE EN LA BD'S. Puede que la diferencia sea mínima, pero será diferencia al fin.
No sé con qué lenguaje de programación estés trabajando, pero sea cual sea, lo más probable es que estés trabajando con un Modelo-Vista-Controlador... ¿cuál es precisamente el objetivo de esta forma de programa? pues el dar independencia a cada una de las capas que conforman el proyecto. El modelo de BD's deberá ser lo más independiente de la lógica de negocio.
Supongamos que trabajas con JAVA e implementas la eliminación con una clase la cual detecta que cuando se elimine algún usuario entonces automáticamente se elimine la deuda asociada al usuario, todo funciona perfecto y no hay problemas de rendimiento ni nos preocupamos por la paz del mundo...
PEEEEEERO, el día de mañana tu cliente/jefe tiene la maravillosa idea de cambia todo tu código y programar en .NET, ¿qué pasa entonces? pues que en .NET tendrías que implementar también tu clase para hacer el mismo proceso.
La ventaja entonces de hacer estos procesos directamente en la BD's creo que es obvia. Si programas tus relaciones en el DBMS's los procesos para la integridad NO DEPENDEN DEL LENGUAJE DE PROGRAMACIÓN, que estés utilizando.
Vuelvo a recalcar lo mismo que dije desde un inicio NO HAY UNA MEJOR FORMA DE HACER LAS COSAS... pero si quieres mi opinión personal/profesional te digo lo siguiente.
1. UTILIZA siempre llaves foráneas.
2. USA siempre JOIN's
3. NO HAGAS COSAS DE BD's desde ningún lenguaje de programación.
4. HAZ CASO OMISO A LOS TRES PUNTOS ANTERIORES, si no aplican para tu caso.
Saludos
Leo
