Duplicar posible:
What’s wrong with foreign keys?¿Debo usar claves externas?
I utiliza MS SQL Server con una gran base de datos sobre 4 GB de datos.
Busco en la web por qué debería usar claves externas. por ahora solo indexé las claves usadas para unir tablas. El rendimiento está bien, la integridad de los datos no es un problema.
¿Debo usar claves externas? ¿Obtendré aún más rendimiento con claves externas?
Una clave externa es principalmente una herramienta para aplicar la integridad de la base de datos, que no está relacionada con la velocidad de ejecución.
Si ya ha optimizado su diseño de índice, entonces probablemente ya tenga estos índices instalados, al menos como índices no únicos. Por lo tanto, no esperaría ningún cambio de rendimiento solo por la instalación de claves externas (que ni siquiera implica necesariamente un índice).
Sin embargo, sospecho un poco de su complacencia con respecto a la optimización de su diseño. usted ya no tiene este concepto clavado.
Lea la documentación de Foreign Keys con el objetivo de comprender lo que hacen para forzar la integridad (vale la pena saberlo en cualquier caso). A continuación, vea si eso no responde su pregunta más completamente.
Las claves externas en realidad no mejoran el rendimiento, de hecho, incurren en una pequeña penalización de rendimiento en todas las operaciones de escritura, para garantizar que se cumple la restricción.
La razón por la que desea utilizar estos es evitar operaciones de escritura destructivas. Si no los tiene, un código erróneo o una sentencia sql incorrecta pueden eliminar las filas que se espera que estén allí.
Las claves externas mejoran la integridad de los datos, el rendimiento, algo más lento al eliminar/insertar/actualizar.
En mi última compañía decidimos mantener la integridad/conexiones en el BL, ya que hace que los cambios en el BL sean más simples (piense en cientos de millones de registros). Si tiene una aplicación pequeña, no veo ninguna razón para no hacerlo en la capa de datos (db)
¿Qué significa BL? – usefulBee
Business layer, capa de datos maneja el código que habla directamente con el db. BL toma esos datos e implementa las reglas de negocio utilizando esos datos, y los envía a la IU. Es una forma un tanto antigua de mirar un software multinivel. Hoy tenemos más de tres niveles/capas y tenemos un sistema ampliamente distribuido para agregar esto. –
Al decir: "decidimos mantener la integridad/conexiones en el BL", ¿se refiere al enfoque de Code First o qué más? – usefulBee
Lo que no se mencionó en la pregunta anterior a la que SquareCog se vinculó anteriormente - sí, las restricciones de clave externa pueden ser dolorosas cuando haciendo limpieza de datos, actualizaciones por lotes, generación de datos de prueba o cualquier tipo de operación en la que elude la secuencia normal de cosas. Pero, siempre puede eliminar sus restricciones de clave externa antes de hacer algo como esto, y luego volver a crearlas más tarde (si tiene los objetos de la base de datos ordenados correctamente, esto no es un trabajo extra).
Solía ser flojo, pero he llegado a depender de las restricciones de clave externa. Todavía hay situaciones en las que no puede tenerlas, como en las relaciones entre bases de datos.
Hay una función/restricción que Foreign Keys aporta a su sistema, que no se ha mencionado hasta ahora. Esa es la lógica de compromiso/transacción (así es como lo llamo de todos modos). Con Foreign Keys habilitada, todas las filas para una actualización, en todas las tablas afectadas, necesitan estar allí para que la confirmación funcione (no arrojar un error de SQL que indique que se han violado las Restricciones de clave externa).
Si tiene un cuerpo de código, que funciona y "juega rápido y suelto", con commits/transacciones. Entonces podría estar en una solución, para hacer que las cosas funcionen con FK en el esquema.
Además, Oracle al menos, le permite desactivar restricciones (no solo colocar/eliminar). Entonces puedes encenderlos/apagarlos fácilmente. Es útil, cuando quiere hacer algunas operaciones masivas ya sea sin la sobrecarga de las restricciones, o para hacer alguna "cirugía" en los datos que tiene estados intermedios que fallarían las restricciones.
Ambos se mencionan en el enlace que publiqué, pero Yo votaré por ti de todos modos. La "lógica de compromiso/transacción" se conoce oficialmente como garantías ACID (la "C" es consistente, como en, una vez que se finaliza una transacción, los datos son consistentes con las restricciones declaradas). – SquareCog
Las claves foráneas también ayudan a mantener su base de datos limpia, ya que puede hacer que la base de datos caiga en cascada.
La integridad puede no ser un problema en la actualidad, pero esa es la actitud exacta que lo convierte en un problema mañana o dentro de dos semanas.
En MySQL puede desactivar clave externa de la SET FOREIGN_KEY_CHECKS=0
"no relacionada con la velocidad de ejecución" no es del todo exacto para las inserciones (sé que lo sabes, pero Tuan tal vez no) – SquareCog
THX - Se me llena la respuesta un poco, de una manera que debería terminar en el mismo lugar. – dkretz
buen argumento sobre la inserción. tengo una buena vista de la estructura. como dije integrety no es problema. necesito velocidad bruta –