Unique o consulta de verificacion?

[leif_sk8er]

Tengo una duda, quiero relacionar terminos de busqueda a usuarios con la siguiente tabla:

busquedas
- ID
- FECHA
- ID_USUARIO
- TERMINO

La cuestion es que no quiero que hayan datos duplicados.

Con lo cual tengo dos formas que se me ocurren para hacer esto:

1. Hacer un indice UNIQUE combinado de ID_USUARIO y TERMINO
2. Desde el script hacer primero una consulta, comprobando si devuelve o no resultados, en caso de que no hace el insert.


Creo que son las dos unicas formas de hacerlo. Mi duda es, cual es mas optima en recursos (generalmente hablando). Me refiero a que el indice combinado ocupa un espacio, y la forma del script hace consultas que usan memoria.... entonces no se que compensa mas.

Por que me decanto?


Un saludo!

[gnzsoloyo]

Hacer un índice UNIQUE sobre dos campos así te devolvería un error al intentar ingresar un par repetido. Es una solución práctica que puede ser funcional si los datos son breves. En el caso de ser muy grande el texto puede plantearse problemas de performance.
El detalle es que debes programar en la aplicación para que verifique si el INSERT/UPDATE ha realmente funcionado y no devuelve un error o un warning. ¿Eso lo tienes claro, no?

[leif_sk8er]

Si, eso lo tengo claro, confirmar que la consulta que ejecute tiene el resultado esperado.

Pero me refiero al paso de antes, a si es mejor hacer un select comprobando si hay ya registros que sigan esos requisitos, o no hace falta por que utilizando unique no valdria la pena?

[gnzsoloyo]

La pregunta en realidad es un poco abstracta en tu caso, pero razonémoslo asi:
1) Si necesitas enviar todos los datos para hacer la comprobación, y los datos son muy grandes, tienes mucho overhead (tiempo de espera entre procesos) de comunicaciones. Puede no ser muy práctico.
2) Si los datos son cortos, puede que sirva, pero tendrás que hacer dos consultas en el peor de los casos (comprobación e inserción), con lo cual te llevará el doble de tiempo.
3) Si simplemente envías y no se puede insertar, recibirás un error de respuesta. Eso es más simple de manejar.
Si es por performance, me quedo con la opción 3, si es por ortodoxia, con la 2.

[leif_sk8er]

Entonces entiendo que es mejor que la base de datos ocupe un poco mas (debido al indice UNIQUE doble creado) si con ello se consigue unos milisegundos mas de velocidad evitando hacer 2 consultas no? Ya que en muchisimas conexiones simultaneas si que se notaria un poco mas drastico.

Por cierto en este caso normalmente son terminos, es decir palabras, raro será el caso que se busque por algo de mas de 100 caracteres, ni siquiera 30.