Campo único en mi BD

[pablitino]

Hola!!

Veréis me he encontrado con el siguiente problema en la implementación de mi BD. Necesito guardar la información de 1000 clientes, la clave primaria de la BD será al nombre y los apellidos de los clientes. Pero a parte me gustaría tener un campo que fuera único para cada cliente, numérico y de tres dígitos (000...999). El problema es que no sé como implementarlo en SQL de forma que sean únicos estos números... He probado con tener un número base e incrementarlo cada vez, pero si se borrara algún cliente, por ej. el 021, este número ya no se podría utilizar, pues simplemente lo que se hace es incrementar un número base de forma que sea menor que 999... No sé si me explico...

He pensado en otra posible solución: tener una tabla más en la BD con un campo ID como clave primaria que sea numérico (000...999) y otro que indique si está siendo usado de tipo lógico (true, false; o en su defecto 0,1). Habría una relación 1,N de la tabla nueva a la del cliente de forma que cada cliente tuviera un único ID de dicha tabla. Al insertar cada cliente, buscaría el primer valor ID de la tabla nueva que esté libre y se lo asignaría (esto lo podría hacer con un procedimiento almacenado, por ej.)

Es una posible solución... pero no creo que sea la mejor...

¡¡Haber si me podéis sugerir una solución mejor!! Muchas gracias, saludos.

[jfw]

Puedes poner un campo autoincremental, que aunque haya huecos y el numero del campo pase de 1000, no tendría ningún significado en tu aplicación. Este campo por definición sería único.
Por otro lado si quieres asegurarte de que no haya más de 1000 usuarios puedes hacer la comprobación antes de realizar una nueva inserción, o meterlo en un triger.

[pablitino]

Si esa idea ya la había pensado, pero como digo, me interesa que el campo único para cada cliente esté en el rango 000...999. Pero si sobrepasa el valor 999 ya no se podrían insertar más clientes, habiendo posiblemente números en el rango que no estén asignados a ningún cliente (por ej. cuando se han ido borrando y se han quedado libres...).

[GreenEyed]

Hola,
Usar como clave primaria de una tabla el nombre y los apellidos no es muy buena idea, de hecho está totalmente desaconsejado, y si va a poder haber bajas o inserciones simultaneas, lo del contador incremental y sin huecos tampoco es demasiado buena idea, a no ser que tengas una necesidad imperiosa y legal, como la numeración de facturas donde es obligatorio.

Si la idea es simplemente controlar que no hay mas de 1.000 clientes, con sincronizar la insercion y contar los que hay antes de meter uno nuevo, listo. Si la cuestion es tenerlos en orden, no hace falta un contador incremental... etc.

Es decir, yo volvería a trás y miraría exactamente que es lo que quieres conseguir y si puedes lograrlo sin tener que usar ese tipo de contador, que te dará muuchos problemas.
S!

[pablitino]

Iniciado por GreenEyed

Usar como clave primaria de una tabla el nombre y los apellidos no es muy buena idea

En cuanto a esto que comentas, tienes toda la razón. De hecho no lo implementé así. Estos serán claves, pero no primarias.

Y en cuanto a lo del campo autoincremental (código de cliente, que será la clave primaria), me explicaré mejor:
No necesito controlar que el número de clientes no exceda en 1000, quiero decir no es esto lo que busco con este código de cliente. El campo código de cliente lo necesito, a parte de que me sirve como clave primaria, por temas relacionados con asientos contables. Mi cliente quiere poder identificar en los asientos a un cliente de manera unívoca mediante un código de tres dígitos.
Mi BD está realizada en Access, lo que busco es un campo único que sirva para identificar a cada cliente de manera unívoca y aprovechando estos "huecos" que comentaba. No sé si Access permite definir un dato de este tipo (por lo menos yo no he encontrado esto). A su vez, y como segunda utilidad, el campo me servirá para que no se sobrepasen los 1000 clientes; pero ya digo que esto es secundario, en cualquier caso se podrían contar antes de insertar.

Espero haberme explicado mejor. Un saludo y muchas gracias por vuestras respuestas.