4 replies to this topic

[cram]

Desconozco el uso y carga del "constraint" Unique_Key.
¿qué es más recomendable?
1. Crear un constraint para evitar nombres duplicados (por ejempo el de una marca) y capturar la excepción cuando ocurra algún caso, o
2. evitar la inserción mediante una búsqueda de la cadena.

No es el caso de identificadores, yo no uso como clave primaria al nombre, sino que lo hago por medio de un ID autoincremental. El nombre es un detalle para otra tabla, pero deseo que sea irrepetible.

Yo me inclino por el primer caso. Pero agradezco si alguien me hace declinar o refuerza mi idea, pues como dije antes desconozco la forma en que firebird maneja estas cosas.

[poliburro]

En una situación como la tuya yo me decidí por crear un índice de valor único. Con muy muy buenos resultados.

[cram]

Gracias por la respuesta.
Es que estoy refaccionando una base de datos para una versión más amplia y quiero hacerlo todo más "automatizado" y más del lado del servidor.

Ahora, lo que no me queda claro: ¿usás un ID para la instancia de entidad más el nombre e indizas ambos? o ¿solo el nombre?

[Sergio]

Si el nombre va a ser unico, podrías no tener un ID, pero yo prefiero un ID para poder hacer ref. sin perder que el nombre sea editable, nunca me gustó abusar del "on udpate cascade", me da miedo!

Ademas un ID que se decida en el oninsert de la table es super comodo, y si la clave primeria es de texto, eso lo pierdes.

[cram]

Gracias Sergio eso me aclara más las cosas.

Pasa que me gusta el uso de los ID, más allá de agregar un campo más, por varias razones. Una de ellas es que es de uso exclusivo, otra es que no forma parte de los datos útiles y visibles para el usuario.

Por lo tanto asignaré como primary al ID_MARCA y como unique al NOMBRE_MARCA. Y listo.
Bueno gracias a ambos, con esto ya tengo decisión.