La mejor opción - y en eso concuerdo con Alex - es usar claves primarias no visibles para el usuario. Por ejemplo, puedes usar números secuencialmente asignados. (En mi artículo en
http://www.utmag.com/May2002/Page14.asp - también disponible en Español - explico algunas de las ventajas y desventajas de ambos enfoques, para crear claves primarias.)
Para los "candidate" todavía tendrás el mismo problema que mencionas; en ese caso, crear un filtro en un índice es la solución adecuada.
Si usas el filtro en la clave primaria, toma en cuenta que el índice no será usado en Rushmore Optimization. Tendrás que tener una segunda versión del índice - regular, y sin filtro - para ser usado en la optimización.
>Buenas tardes Amigos de Universal Thread:
>
>Les cuento que estoy trabajando un form de ingreso de datos sobre una tabla que posee el índice primary. Eliminé luego un registro y posteriormente volví a crearlo con el mismo valor de llave del que había eliminado previamente y me generó el mensaje de clave duplicada.
>
>Después de mucho gruñir un muy buen rato probando varias alternativas para evitar el mensaje, puse un filtro en la definición del índice "primary" para que no tomara en cuenta los registros eliminados y funcionó, y estoy feliz, pero...
>
>¿Esta es la solución para el inconveniente o hay otra más adecuada?
>¿Esta solución puede causarme futuros dolores de cabeza, es decir hay algo más que deba tener encuenta?
>
>Muchas gracias amigos.
>
>Atn.
Difference in opinions hath cost many millions of lives: for instance, whether flesh be bread, or bread be flesh; whether whistling be a vice or a virtue; whether it be better to kiss a post, or throw it into the fire... (from Gulliver's Travels)