Pensa a nivel base de datos, suponete que usas un codigo alfanumerico como PK
de una tabla. Si tuvieras otra tabla con una FK a la primera, este seria un
campo alfanumerico tambien y de esa manera estas ocupando mas espacio que el
que ocuparia un long. Ademas las comparaciones de las consultas tardan mas
tiempo cuando se trata de comparar campos alfanumericos. Es por eso que
generalmente se usa un long ya que no molesta y te ahorras problemas, pero bien
podrias usar un PK compuesta si quisieras aunque en lineas generales no tienen
ventaja alguna.
Tu problema particular de que si usas un long como PK no podes validar
naturalmente que un campo sea unico se resuelve si usar equals, no hace falta
que un campo sea PK para que sea UNIQUE, o sea si queres que tu campo nombre
sea unico y no pertenezca a tu clave primaria simplemente agrega en tu base de
datos una constraint unique al campo nombre y listo. Eso en la entidad se ve
reflejado colocando una annotation de JPA en donde indicas que ese campo es
unique, incluso creo que esa misma annotation podes usarla con Hibernate
Validator para hacer las validaciones de negocio, pero nunca investigue
demasiado.
Siempre fijate si podes evitar el equals, por ejemplo tal vez no haga falta
usar un contains de una coleccion para saber si un elemeno esta o no, tal vez
te convenga directamente ejecutar una query con algun WHERE y si la coleccion
que te retorna esta vacia es porque el elemento no existe. Al reducir al minimo
el uso del equals vas a llegar a la conclusion que con un equals que solo
analiza id alcanza, si no es asi entonces yo escogeria tu opcion numero 3 en
donde en lugar de implementar mi metodo equals2 implementaria un metodo que
valide cada regla de validacion en particular para que esas reglas de
validacion se vean claramente reflejadas en el codigo, esos metodos los pondria
en una clase aparte que llamaria Validator.
Date: Mon, 25 May 2009 14:21:18 -0300
Subject: Re: [Prog] Base de datos + Id numerico en vez de identificador natural
de la entidad + java
From: [email protected]
To: [email protected]
Hace rato que no uso Hibernate, pero si no mal recuerdo, una de las buenas
razones para usar un id por separado,
era que le podías indicar a Hibernate que lo asigne automáticamente. De esta
manera, te desligás de la tarea de mantener la consistencia en la base de datos
desde tu código de entidad.
De hacerlo así, no deberías usar el id de la base en el equals/hash, por que
estos se generarán una vez que persistas el objeto (y realmente no tienen
significado "de negocio"). Acá se discute esto:
https://www.hibernate.org/109.html
Saludos.
El 25 de mayo de 2009 13:07, Victor Del Rio <[email protected]>
escribió:
Buenas, estoy trabajando con un modelo en java que va a persistir con
hibernate y me surgio una duda:
1. ¿Porque usar un id numerico (ej: Long id) envez de usar los campos
que realmente identifican a la entidad?
Yo me imagino que sera por el tema de el tamaño que tomaría la base
de datos.
Pero el tema es que eso, y usar el hashCode y equals con el id no
me permiten validar naturalmente
algunas reglas del negocio como por ejemplo si yo no quiero que
haya dos o mas entidades del mismo
nombre (porque ese era su identificador natural) ya no me sirve el
equals, ni el contains de
collection ni nada.
Entonces me surgen tres opciones de las cuales no se cual es mas
conveniente, talvez inclusive alguna no sea valida:
1. No uso id numerico sino que uso los identificadores naturales
(ej: nombre, dni) y uso tambien estos
para el hash code y equals.
2. Uso los id numericos pero en hash code y equal uso los
identificadores naturales.
3. Uso los id numericos, tambien en el hash code y equals, pero
agrego un metodo mas a las clases entidad que
compare por los identificadores naturales (algo asi como
"obj.igualSegunNegocio(otroObj)") y uso ese metodo
para comparar en el modelo.
Bueno agradezco cualquier sugerencia, saludos.
_______________________________________________
Lista de correo Programacion.
[email protected]
http://listas.fi.uba.ar/mailman/listinfo/programacion
_________________________________________________________________
¿Uno por uno? ¡Mejor todos a la vez! Sumá a tus amigos a Windows Live
http://www.microsoft.com/argentina/windows/windowslive/products/social-network-connector.aspx_______________________________________________
Lista de correo Programacion.
[email protected]
http://listas.fi.uba.ar/mailman/listinfo/programacion
