Al mon de la teoria de Base de Dades a aquestes claus no semàntiques es coneixen com a surrogate keys i, tot i que tenen detractors, es fan servir a tot arreu.
Cada fabricant de base de dades ha implementat aquesta funcionalitat de forma diferent. Informix té els
SERIAL
, Microsoft SQL Server els IDENTITY
i MySQL té l'atribut AUTO_INCREMENT
. Hi ha una comparació de mecanismes de generació de claus força interessant, que també explica cóm proposa l'estàndard que s'hauria d'implementar (que les anomena IDENTITY
).El que més s'allunya de l'estàndard és Oracle. Té un element extern a la taula que genera els números, la
SEQUENCE
, que s'ha de fer servir per obtenir els valors abans de fer un INSERT
amb l'operador NEXTVAL
.Res obliga a fer servir una
SEQUENCE
determinada amb una taula, o no fer servir cap. Per aquesta raó és fàcil que es donin casos anòmals. Pot succeir que la taula T(id, camp)
contingui registres amb els valors per id
1, 12, 23 i 53, i que la seqüència que s'acostuma a fer servir per les seves insercions tingui el valor 24 per què, per exemple, algú ha inserit el valor 53 sense fer servir la seqüència. Podrem fer insercions fent servir la seqüència fins que s'arribi al valor 53, que ens donarà un error al trobar un valor duplicat.Aquesta descorrelació entre
SEQUENCES
i valors a les taules és més freqüent del que sembla, i no té una solució general. De fet, aquest problema es pot produir si has fet una exportació d'una base de dades mentre estava en activitat, ja que primer exporta les metadades (i les seqüències ho són) i després les dades i fa les dues operacions amb bloquejos diferents.A més a més Oracle no permet fer un modificació directa del valor que vols que retorni la seqüència, la qual cosa ho complica tot encara més, ja que hauràs d'esborrar la seqüència i tornar-la a crear i pot ser que descompilis procediments, paquets i disparadors.
A la segona part veurem tècniques per sobreviure a aquests problemes amb les
SEQUENCES
.Segona part: Seqüències d'Oracle (2 de 2)
No comments:
Post a Comment