Re: [OT] como lograr campo consecutivo sin fallar ?

El día 24 de julio de 2008 12:56, Sebastián Villalba
<sebastian(at)fcm(dot)unc(dot)edu(dot)ar> escribió:
> Hola...
>
> On Thu, 24 Jul 2008 09:41:13 +0200, Miguel Rodríguez Penabad wrote
>> >> Bueno, todos los atributos que un humano pueda tocar son malas opciones
>> >> para una llave primaria.
>> Yo estoy 100% EN CONTRA de esta sugerencia.
> ¿Por qué?

(Añádo OT porque esto ya casi es off-topic...)

Por ejemplo, porque es más difícil hacer controles, o porque
examinando datos estos identificadores no tienen ningún significado.
Y porque si un identficador natural existe, añadir otro es duplicar
trabajo. Por ejemplo, si yo sé que con mi número de seguridad social
identifico un empleado, al añadir un id subrogado estoy obligado a
mantener las dos claves: el identificador y el nss, ya que si no digo
que el NSS es unique y not null estoy permitiendo introducir datos
incorrectos, pero si introduzco la restricción unique, esto me va a
crear otro índice que hay que mantener.

Es un tema de los de "flame war" en el mundo de las bases de datos,
así que yo sólo expongo mi opinión particular, que no tiene que ser
la acertada.

>> De hecho, encuentro que se abusa demasiadas veces de campos serial y
>> similares, y en mi universidad en concreto viene de (de nuevo es mi
>> opinión) una orientación a objetos en el desarrollo de software que
>> da demasiado poca importancia al diseño de las bases de datos.
>
> Bueno, esa es una falencia de tu universidad. El paradigma de orientación a

(primero: gracias, no conocía la palabra falencia :))
Y luego: no sólo de mi universidad, como indico más adelante.

> objetos es algo realmente fascinante. De todas formas, aplicar correctamente
> la teoría de orientación a objetos, no implica descuidar una parte tan
> esencial como un buen diseño de la base de datos.
> Hay varios patrones de diseño (patrones Dao o Factory por mencionar un par que
> pueden inclusive ser combinados) que hacen de forma muy elegante una
> implementación de persistencia de objetos utilizando base de datos relacionales.

Conozco los patrones de diseño, pero si se usan mal, estamos en las mismas.
Y estoy de acuerdo en que la orientación a objetos es una aproximación muy
buena al desarrollo de software. Pero siempre hubo, hay y habrá problemas al
tratar de hacer converger 2 mundos como el relacional y el OO.

Antes decía que no era sólo problema de mi universidad, y que está más
extendido.
Por ejemplo, considera las herramientas de mapeo objeto-relacional,
como Hibernate.
Este funciona maravillosamente bien si tienes esos IDs subrogados,
pero con claves
compuestas ya va peor. Y no permite cambiar la clave primaria.
En concreto, en una introducción del libro (creo) Hibernate in action,
de la prestigiosa
editorial Manning, dice que una clave primaria en una bd relacional es algo
"no nulo, único e inmutable", y esta definición, que le cuadra muy
bien a Hibernate y al
paradigma OO en general, es estricta y objetivamente INcorrecta. Lo de
que una PK es
inmutable es mentira, pero como si no la hacemos inmutable hibernate
no va, pues se
sacrifica el modelo relacional.
He revisado por encima JDO e iBatis y creo que trabajan igual... así
que me veo en un
futuro teniendo que "pasar por el aro" de los identificadores.

> Yo estoy de acuerdo con Gunnar de que conviene que a las claves primarias las
> maneje el motor con la menor intervención humana posible, que cuando
> permitimos que los buenos operadores, DBA y/o gente de confianza modifique
> esos campos, a la larga aparecen inconsistencias en los datos (a menos que
> estén correctamente definidos *todos* los constraints necesarios).

Tampoco estoy de acuerdo en que se puedan producir inconsistencias si
se modifican claves primarias. Para mi está clarísimo que se *deben* definir
todas las restricciones.

>
> Es mi opinión solamente. Saludos...

Idem. Un saludo desde el otro lado del charco, y perdón por el
ladrillo que acabo de escribir.

--
Miguel Rodríguez Penabad