Mientras escribía una consulta el otro día, se me ocurrió una idea que se me quedó grabada.
¿Qué es preferible, primero verificar si existe un valor para una columna única y luego insertar o insertar y dejar que db genere un error de restricción único? ¿Importará?
Editar: como se sugiere a continuación en respuesta que este problema depende de la base de datos, estoy agregando la etiqueta postgresql.
Respuestas:
No creo que su pregunta sea realmente independiente de la base de datos. La respuesta correcta podría depender de los detalles de implementación, que pueden variar de un proveedor a otro y cambiar con la próxima versión. Probaría bajo concurrencia antes de elegir cualquier enfoque en cualquier RDBMS.
En este momento, en SQL Server 2008 R2, estoy usando lo siguiente:
Baja concurrencia y baja cantidad de modificaciones. Para guardar una sola fila, serializo usando sp_getapplock y uso MERGE. Pruebo de estrés bajo alta concurrencia para verificar que funcione.
Mayor concurrencia y / o volumen. Para evitar la concurrencia y aumentar el rendimiento, no guardo una fila a la vez. Acumulo cambios en mi servidor de aplicaciones y uso TVP para guardar lotes. Aún así, para evitar problemas relacionados con la concurrencia, serializo usando sp_getapplock antes de MERGE. Una vez más, hago una prueba de estrés bajo alta concurrencia para verificar que funcione.
Como resultado, tenemos un buen rendimiento y cero problemas relacionados con la concurrencia en la producción: sin puntos muertos, sin PK / violaciones de restricciones únicas, etc.
Deje que el DB genere un error.
La prueba primero no es segura para la concurrencia porque eventualmente obtendrá una colisión porque 2 hilos pueden pasar "NO EXISTENTE" y ambos intentarán escribir. Esto se aplica tanto a las estrategias de bloqueo "LEER COMPROMETIDO" como MVCC / Instantánea.
Puede usar sugerencias de bloqueo para forzar el aislamiento, pero reduce el rendimiento.
Yo llamo a esto el patrón JFDI (enlace SO). Para "actualizar si existe", vea esto aquí: Necesita ayuda Solución de problemas de Sql Server 2005 Deadlock Scenario . Estos son SQL Server. MySQL tiene INSERT IGNORE que maneja esto con gracia. No estoy seguro del resto
MERGEque pueden haber resuelto las observaciones de Paul, pero no lo he probado a altas tasas de transmisión. Principalmente porque todavía tengo que entrenar mi cerebro para entender esa sintaxis.