Clave principal
Santi
A la hora de escoger una clave principal ¿hay alguna diferencia en
cuanto a rapidez o eficiencia entre escoger un DNI o un campo identidad?
Gracias
Miguel Egea
ocupara 12 a 15 digitos, y solamente en compararlos se tarda mucho más que
en comparar 2 números que caben en los registros del procesador. Además de
eso, y aunque tengas un indice clustered, este será mucho más facil de
mantener en un autonumérico que solamente crece, mientras que en un dni no
es ascedente siempre, cada vez que des de alta un elemento puede ser que
tengan que hacerse operaciones especiales para insertarlo físicamente en su
sitio. Además los autonuméricos te evitarán bastantes problemas de
concurrencia bajando incluso mucho el nivel de aislamiento (isolation
level).
--
Un Saludo
Miguel Egea
http://www22.brinkster.com/miguele
PASS Spanish Group
Microsoft MVP SQL-SERVER
"Santi" <rom...@telsp.es> escribió en el mensaje
news:#iL0SciMCHA.2200@tkmsftngp08...
Emilio Boucau
esta vez yo discrepo contigo ! Me ha tomado casi 3 tres años tambien ...
jejeje
Yo utilizaria como clave el DNI y no un campo IDENTITY. Eso para mi no tiene
sentido logico ya que si la unica ventaja que te dara el uso del ID frente a
un dato real sera al momento de insercion, a menos que tengas cargas masivas
de datos en esa tabla, la diferencia no sera muy significativa. Ok, tenes
razon; a lo mejor el ID demora una micronesima de segundo en insertar y el
DNI demora 3 micronesimas con lo cual el otro es 3 veces mas rapido... pero
el impacto real es despreciable.
Cual es el motivo de que no use un ID ? Pues bien, si se desean usar esos
datos como la gente y realizar busquedas, deberas tener un indice por la
columna DNI que, a su vez, deberas barrer tambien para asegurarte de no
insertar un DNI duplicado al momento de agregar una fila de ID incrementado;
se entiende ? Entonces, si ya hiciste la busqueda por el indice para validar
que no este (o indice compuesto ID/DNI unique...) creo que ganaras plata
usando el DNI directamente.
Por otro lado, el tema de una clave es que te identifique univocamente un
registro, mucho mas alla de numerarlos secuencialmente solo para que sean
diferentes ... Eso para mi es valido al momento de hacer grandes cargas de
datos en tablas temporales que luego se volcaran a las definitivas, pero no
es criterio para usar en tablas de sistemas con datos reales ya que una vez
que estan insertados, para que queres el ID ?
Ya vez, Miguel ... no pierdas la espeeranzas !
Te mando un abrazo !
"Miguel Egea" <migue...@sinergiatec.com> wrote in message
news:u8jVUJjMCHA.1644@tkmsftngp11...
Enrique Albert
polemica pero hay un pequeño detalle que no me gusta en SQL 2000 con primary
keys que son varchar o nvarchar. El pequeño problema que se plantea en SQL
2000 son las collations.
Usar varchar para hacer uniones en SQL 2000 puede plantear algunos problemas
adicionales cuando se crea aplicaciones, hay que usar collation
constantemente para asegurarse no va a existir problemas con las uniones de
tablas en diferentes servidores y BD, especialmente la tempDB. Solo por eso
yo recomiendo utilizar un indice numerico aunque implique una mayor carga
para el mantenimiento de la tabla como indica Emilio.
Solo es mi opinion.
Emilio Boucau
no es una polemica de ninguna manera y toda opinion es bien recibida.
Saludos !
Miguel Egea
experiencias, como por ejemplo que el usuario no lo sabe, y la empresa no va
a dejar de hacer una venta, por otra parte, efectivamente cuando la clave es
claramente única pues casi que es así, pero cuando las claves son compuestas
( artículo(familia,subfamilia,sección,codigo) )en mi opinión es mejor un
autonumérico y restricciones únique sobre el conjunto de columnas que
conforma la clave alternativa. Los joins con otras tablas són más rápidos
eficientes y cortos de escribir (que también es importante), pero como tu
dices será cuestión de gustos.
Emilio, en un par de semanas dos desacuerdos y en tres años cero, ... vamos
a tener que tomarnos algunas cervezas a ver si en eso tenemos más
coincidencias ;-) jeje
--
Un Saludo
Miguel Egea
http://www22.brinkster.com/miguele
PASS Spanish Group
Microsoft MVP SQL-SERVER
"Emilio Boucau" <bou...@towers.com> escribió en el mensaje
news:e4Ah01kMCHA.772@tkmsftngp12...
Salvador Ramos
No quiero entrar en la polémica :-))
Pero hay un dato muy importante a tener en cuenta, no desde el punto de
vista técnico, sino desde el funcional. En España hay DNI duplicados, y en
empresas con un volumen relativamente bajo/medio de clientes no suele haber
coincidencias, pero en otras si que las tiene. Yo he trabajado en varias
entidades financieras, y allí siempre utilizan una clave primaria distinta,
ya que entre sus clientes hay DNI duplicados (cada vez son menos, pero al
menos en España, sigue ocurriendo).
--
Un saludo
---------------------------------------
Salvador Ramos
www.helpdna.net (información sobre Windows DNA, SQL Server, Visual Basic,
...)
webm...@helpdna.net
---------------------------------------
PASS Spanish Group (www.sqlpass.org)
---------------------------------------
"Miguel Egea" <migue...@sinergiatec.com> escribió en el mensaje
news:O9DX58kMCHA.560@tkmsftngp08...
Emilio Boucau
creo que las vas a pagar vos a las cervezas, aunque yo prefiero
personalmente Quilmes (cerveza argentina), coincidimos en eso o tampoco ...
? ;-)
En el caso de las familias que mencionas, ese codigo sera unico pero se ira
creando por la concatenacion de los subcodigos anteriores ... jamas un
IDENTITY !! No es logico ni representativo !!
Tenes una tabla de familias con su ID, una tabla de subfamilias con su ID,
las secciones con su ID y el codigo, todo eso concatenado te dara el codigo
unico que deseas para cada articulo. De esta forma, podes 'leer' un codigo
de un articulo y te da informacion real, no solo un ID unico.
Con respecto al DNI, si es requisito para la venta es simple: o el analisis
no esta bien hecho y no es obligatorio realmente o si es obligatorio y no lo
tiene/sabe no deberian venderle. Es como hacer una operacion con tarjeta de
credito y no solicitar una identificacion, si luego resulta que esa tarjeta
es robada la perdida sera para el comerciante.
Obviamente, es cuestion de gusto y preferencia personal.
Otro abrazo !
Miguel Egea
la probare este fin de semana a ver si en eso si coincidimos :-)
Carlos Sacristán
Puedo meter yo tb la cabecita? Es que me gusta discutir ;-)
A mí personalmente, los autonuméricos me gustan bastante porque son
fáciles de manejar, al ser pequeños (comparado con lo que puede ser una
clave como el dni) son muy eficientes y lo que decía Miguel, las uniones
entre tablas resultan de ese modo más sencillas. Por eso seguramente hubiera
escogido como PK el campo identity, no sólo por ser más rápidos a la hora de
insertar (la diferencia es mínima, como comenta Emilio), sino también pq las
búsquedas lo serían igualmente.
Ahora bien, estoy de acuerdo en que parece no tener mucho sentido tener
que crear otro campo clave en la tabla cuando parece que con el DNI
bastaría. Lo que ocurre es que éste es un caso particular, puesto que como
bien dice Salvador, estos documentos en España no tienen por qué ser únicos.
Sí, la posibilidad de que esto ocurra es ínfima, pero existir, existe.... y
si te toca la china.
Así que, así, sin tampoco darle muchas vueltas al tema, creo que
escogería el tema del autonumérico y le pondría un índice (no único) como
una casa al dni.
Conclusión: Emilio, somos dos contra uno... jejejejejjeje
--
Un saludo
--
--
----------------------------------------------
"Sólo sé que no sé nada. " (Sócrates)
"Emilio Boucau" <bou...@towers.com> escribió en el mensaje
news:#0jtSJlMCHA.1748@tkmsftngp09...
David Barrabés
con esto de los DNI.
Es cierto que si has de trabajar con diversas bases de
datos mejor lo hagas con un dato numérico.
Por otro lado, si lo único que quieres es tener una tabla,
llamemosla 'inicial' con ese DNI i a partir de ahi, en las
siguientes tablas utilizas numéricos tendras,
aproxiamadamente, lo mejor i peor de los dos metodos. Y
para que esto se entienda
create table datos
DNI varchar(10) primarykey
....
create table registros
IdReg numeric primary key
DNI varchar(10) foreign key
....
Esto permitira asociar mas de un registro a un mismo DNI,
o, si le pones una restriccion UNIQUE al DNI de la segunda
tabla, un sólo registro.
>-----Mensaje original-----
>.
>
Emilio Boucau
ya que metes la cabeza, la ligas vos tambien ...
el DNI es numerico, no char ni varchar ni nada asi, dado que es un numero y
no incluye caracteres ... Hacer ese campo char no tiene mucho sentido, con
lo cual seria tan pequeño y 'atletico' como tu autonumerico y en eso
concordamos plenamente. Punto descartado.
Aunque un caso como el planteado como el que decis no resiste analisis, ya
que supongamos que en España no tengas numeros duplicados, ok (para que no
te toque la china, como decis), como harias para tener dos veces de cliente
a la misma persona ? Alli tendrias duplicados quieras o no (sean o no la
misma persona fisica), con lo cual es como dije antes: esta mal hecho el
diseño y esa no es la PK real; sera un dato importante, pero no la PK ...
Aca en Argentina tambien tenes numeros de DNI repetidos pero pertenecen a la
misma persona (sin hablar de documentos falsos, verdad?); mi DNI es un
duplicado debido a la 'destruccion fisica total del documento en cuestion'
(como se leia en la presentacion que hice ante la policia para luego
solictar una renovacion ...), pero aca la PK seria el numero de DNI y la
version del mismo ... Eso no genera duplicados !
Carlos, anda a buscar mas ayuda ... dos no son suficientes ... jejeje ...
Pero acordate que por aca hay varios argentinos tambien y (al menos) una
compañera de Mar del Plata, que tambien daran su punto de vista del tema ...
(yo ya hable con ellos y opinaran de mi forma !)
Un abrazo para todos !
Liliana Sorrentino
silencio cuando hablan los maestros.
Opino como me dijiste que lo hiciera: si bien tenemos solo un sistema con el
documento como clave, el volumen de la información entre las tablas no
supera los 3.000.000 y no me parece suficiente para hablar de rendimiento
que hasta ahora es excelente (sino como les decimos a los contribuyentes que
además tienen que pagar)...
Desde la consulta inicial de Santi estoy siguiendo este hilo para ver si
encuentro motivos suficientes para rediseñar ese trabajo, o tenerlo en
cuenta para alguno nuevo. Pero no podía dejar de asentir con la cabeza
cuando leía tu respuesta de ayer a las 11:08.
Con respecto a la Quilmes, tengo entendido que ya no es totalmente
nacional...¿será cierto? A lo mejor ya no nos queda ni el "Legui".
Saludos a todos... los esperamos por Mar del Plata.
Liliana.
Emilio Boucau
Saludos para todos !
Eladio Rincón
"Liliana Sorrentino" <lsorr...@mardelplata.gov.ar> escribió en el mensaje
news:uVcHA7xMCHA.2096@tkmsftngp10...
> Acá estoy Emilio, solo que en el colegio me enseñaron a mantenerme en
> silencio cuando hablan los maestros.
A mí en el colegio me decían lo mismo, pero me he llevado más de un castigo
por no callarme la boca ;-)
Parece que esto lleva camino del debate: "Relacional, no relacional". El
otro día leí que "una persona que lleva puestos dos relojes no sabe qué hora
es", y aquí parece que se cumple:
* Si usamos como PK un campo entero autonumérico ( los puristas lo llaman
"PK artificial"), tendremos cubierto el supuesto de M.Egea y S.Ramos, es
decir, que el DNI se repita, o que al comercial de turno no le haya
apetecido introducir el DNI del cliente que acaba de crear (MUY frecuente
por estos lares ... ).
- El problema del comercial se solucionaría presentando el análisis al
comercial para que trabaje como hemos especificado que nuestra aplicación
funciona.
- El problema comentado por Salvador nos llevaría a tener que buscar otra
clave candidata porque claramente si hay dos DNI's iguales no puede ser
clave primaria. Entonces ahora es cuando se debería decidir entre una clave
primaria "artificial", o tener que buscar otra clave primaria entre el resto
de columnas de la tabla ( joeee en el caso peor tendríamos como clave
primaria ( nombre, apellido ). Pregunta para Emilio: Ahora ya sería bastante
más razonable sacar una clave primaria "artificial", ¿verdad?
* Si usamos como PK un campo que identifique la fila, el Entidad Relación
estará en 3FN y no tendremos el problema de los relojes:
- Se ha comentado de la eficiencia de los JOIN, pero el único caso en que no
tendrías que hacer JOIN con la tabla de clientes sería cuando buscases una
factura del cliente que tiene el DNI '222223', porque cuando busques las
facturas del cliente 'MARTINEZ' habrá que hacer un JOIN, por lo que parece
que SI va a ser frecuente hacer consultas con JOIN tanto con PK Real como PK
Artificial.
- El tamaño ocupado por las tablas. Además de lo que ocupe cada registro de
la tabla clientes, habrá que ver todas las tablas que vayan a tener clave
ajena a la tabla clientes ( facturas, lineas de factura, albaranes,
descuentos de factura, lineas de descuento de factura, ...., con albaranes,
... ) Afectará a un montón de tablas por lo que el tamaño SI que importa
qué comentario más picarón :-D )
Creo que mi voto es 1/2 punto para los de la PK artificial y el otro 1/2
para los de la PK natural. JEJEJE así me invitan a (b)(b)(b) los dos grupos
:-P
En serio: creo que habría que sopesar si es realmente clave primaria el DNI
y si el rendimiento puede llegar a no ser el deseado (la eficiencia del
tamaño).
Eladio
Miguel Egea
un mix :-D.
Que sepais que la culpa de el hilo la tiene Boice Coll (o como puñeta se
escriba) jeje
--
Un Saludo
Miguel Egea
http://www22.brinkster.com/miguele
PASS Spanish Group
Microsoft MVP SQL-SERVER
"Eladio Rincón" <tvel...@torrevieja.infoville.net> escribió en el mensaje
news:##eP#B3MCHA.1636@tkmsftngp12...
Carlos Sacristán
Eladio, eso es trampa, te tienes que poner del lado de alguno de los dos
bandos ;-)
Hablando ya en serio; o me he perdido algo o a estas horas de la mañana
todavía mis legañas no me dejan leer bien, porque comentas que cómo haría
para tener dos veces como cliente a la misma persona. No lo entiendo muy
bien, puesto que lo que haría sería diseñar la tabla de personas con la que
luego se relacionarían las tablas que fueran necesarias...
De todos modos, la pregunta inicial fue que qué era más eficiente como
clave principal, un autonumérico o el dni de la persona, y me parece que,
aunque pequeña, la diferencia está a favor del primero.
Otra cosa es que un numerajo no sea identificativo de la persona, que es
más claro que sea el DNI, pero ahí entran más cuestiones: que no es único,
que muchas veces la persona no está dispuesta a facilitarlo, que no es
creciente siempre....
Bueno, pues ahí queda eso...
--
Un saludo
--
--
----------------------------------------------
"Sólo sé que no sé nada. " (Sócrates)
"Eladio Rincón" <tvel...@torrevieja.infoville.net> escribió en el mensaje
news:##eP#B3MCHA.1636@tkmsftngp12...
Salvador Ramos
(perdón, yo no quería, pero mis dedos han escrito esto sin mi
consentimiento)
Pd. A lo de hablarlo con las cervezas, me apunto (espero que sea pronto) (b)
--
Un saludo
---------------------------------------
Salvador Ramos
www.helpdna.net (información sobre Windows DNA, SQL Server, Visual Basic,
...)
webm...@helpdna.net
---------------------------------------
PASS Spanish Group (www.sqlpass.org)
---------------------------------------
"Miguel Egea" <migue...@sinergiatec.com> escribió en el mensaje
news:ecSf3Q6MCHA.1644@tkmsftngp11...
Eladio Rincón
cada nombre que no hay quien los entienda, y luego quieren que se les haga
caso.
:-DDD
Eladio
"Miguel Egea" <migue...@sinergiatec.com> escribió en el mensaje
news:ecSf3Q6MCHA.1644@tkmsftngp11...
Eladio Rincón
"Carlos Sacristán" <csacristanARROBAocasoPUNTOes> escribió en el mensaje
news:e7Ak2a6MCHA.2372@tkmsftngp11...
>
> Hablando ya en serio; o me he perdido algo o a estas horas de la
mañana
> todavía mis legañas no me dejan leer bien, porque comentas que cómo haría
> para tener dos veces como cliente a la misma persona. No lo entiendo muy
> bien, puesto que lo que haría sería diseñar la tabla de personas con la
que
> luego se relacionarían las tablas que fueran necesarias...
>
He revisado de nuevo el mensaje pero no he podido interpretar el comentario
que haces.
> De todos modos, la pregunta inicial fue que qué era más eficiente como
> clave principal, un autonumérico o el dni de la persona, y me parece que,
> aunque pequeña, la diferencia está a favor del primero.
>
Creo que ha quedado claro en los mensajes de otros compañeros que cuanto
menos bytes ocupe la clave primaria más efectivas serán las búsquedas. Por
eso creo que lo que se ha comenzado a debatir es si se debería aprovechar el
mejor rendimiento (con claves primarias artificiales ) frente al
identificador natural ( inicialmente se apostó por el DNI ). De ahí venía el
comentario de que "una persona con dos relojes no sabe qué hora es": un
reloj sería la PK artificial, y el otro reloj sería el DNI.
Un saludo (b)(b)(b)
Eladio.
Carlos Sacristán
Pero Eladio, ¿qué haces por aquí estando de vacaciones?. ¿No te da
vergüenza? ;-)
El primer comentario no iba para tí, sino para Emilio, por eso no lo has
pillao.
En cuanto a lo otro, me perdí en algún momento... sorry. Y si quieréis
mi opinión sobre ello, es que prefiero un identificador único (el identity,
aunque no sea muy claro) que la concatenación de varias claves. Pero bueno,
creo que eso es una cuestión de gustos...
A ver si podemos seguir discutiendo esto en un sitio más tranquilo con
unas cervecitas y unas cañitas... jejejejeje :D
--
Un saludo
--
--
----------------------------------------------
"Sólo sé que no sé nada. " (Sócrates)
"Eladio Rincón" <tvel...@torrevieja.infoville.net> escribió en el mensaje
news:eaKI767MCHA.2420@tkmsftngp11...
Salvador Ramos
Codd. Estos ingleses nos van a volver locos ;-)
--
Un saludo
---------------------------------------
Salvador Ramos
www.helpdna.net (información sobre Windows DNA, SQL Server, Visual Basic,
...)
webm...@helpdna.net
---------------------------------------
PASS Spanish Group (www.sqlpass.org)
---------------------------------------
"Eladio Rincón" <tvel...@torrevieja.infoville.net> escribió en el mensaje
news:#aEq#67MCHA.2420@tkmsftngp11...
Emilio Boucau
no hace falta quedar bien con Dios y con el Diablo para tomar unas cervezas
(aca con Liliana y conmigo te tomas unas Quilmes retranquilo... )
Si una persona lleva dos relojes y no sabe que hora es, se debe a que no los
ha seteado correctamente, porque para despistar, con uno solo dato erroneo
alcanza... ;-)
Con respecto a tu planteo, no esta del todo mal pero mira esto: si tu
problema es evitar que se te repita el DNI, quiere decir que no es la PK ya
que el DNI sera dato unico !!! Ya lo dije antes, es un diseño erroneo! No le
pongas un generador de valores secuenciales solo para identificar datos !
Analiza mejor !
Si sabes que vas a tener repetidos eso no es una PK y no vale de nada que la
'disfraces'... Aca en Argentina, donde no tenemos duplicados es seguro que
el DNI sea la PK y sea FK en otra tabla tambien, pero esa libertad te la da
la misma naturaleza unica del dato.
Respecto a los JOINs, no usarlos es embrollarse la vida porque estas son
bases de datos relacionales, con lo cual estan orientadas y optimizadas para
que uses JOIN ! Es mas, los JOINs son una de las herramientas mas poderosas
de las bases de datos. Suponete que no pudieras hacer JOIN, que problemon,
no ? Esto te brinda flexibilidad en el diseño y en las consultas.
En este caso, tenes razon acerca del tamaño del dato ... coincidimos de
pleno.
Yo sostengo que la PK es el DNI solito en una tabla que no va a aceptar
repeticiones y sera FK en una tabla de detalle del mismo. En vuestro caso
donde tienen duplicados, deberian hacer la clave compuesta con otro dato
unico referente a la persona. Lo mismo con identificaciones tributarias de
empresas ... son unicas !
Ya puse las cervezas en la heladera, vos trae los vasos ... ;-)
Un abrazo !
Fernando G. Guerrero
(por aquello de que dos españoles tres opiniones, y supongo que por
extensión 20 hispanos 30 opiniones).
Mirando desde el punto de vista del diseño conceptual de una base de datos,
no hay más claves que claves naturales, ya que los únicos atributos que se
deberían utilizar son atributos que sean identificables desde un punto de
vista de realidad de negocio. Esto es válido tal cual, y una clave natural
podría ser el DNI. El problema es que lo que llamamos DNI es muy diferente
en cada país. En España no es un número (lo era), sino un conjunto de un
número y una letra para validar dicho número, de ahi la necesidad de
almacenarlo como alfanumérico (aunque la letra se podría calcular
automáticamente). La razón por la que se añadió la letra fue para evitar
errores al dictar DNI, por "ofuscación transitoria o declarada picardía del
operario o sujeto en cuestión" (copiando a mi querido y admirado profesor D.
Manuel Chueca).
En otros países se ha intentado incorporar a la población un DNI sin éxito,
hasta en algunos casos varias veces en los últimos años, con lo que tienes
casos como el de Bolivia, en el que existen tres tipos distintos de DNI
(todos con diferentes formatos y todos alfanuméricos) y en los que el
conjunto de dichos tres formatos no llegan a alcanzar al 30% de la
población.
Por otro lado, uno de los factores para la selección de la clave primaria
debería ser la inmutabilidad de los valores que este atributo almacena. Por
ejemplo, el código de producto podría no ser un buen candidato para clave
primaria si se espera que cambie en el futuro.
Otro caso es la implementación física de dicha clave primaria. En este caso,
podríamos tener en cuenta diferentes factores:
Si el campo DNI va a participar en muchas búsquedas debería estar indexado.
Dado que dudo que se ejecuten consultas de rangos de DNI, este no es un buen
candidato para índice agrupado (clustered), así que sea clave primaria o no,
no debería crearse como clustered.
Si se espera que existan campos de DNI desconocido, no se puede crear ni una
clave primaria ni una restricción única a este campo (aunque se podría crear
una vista que filtrara los campos no nulos, indexada con un índice único).
Si no se espera obtener repeticiones de DNI, todos los beneficios de una
clave primaria se podrían aplicar del mismo modo a un índice único, por lo
que no existiría diferencia operativa en este caso. La diferencia de nombre
entre clave primaria e índice único entre campos que no aceptan valores
nulos no representa ninguna diferencia en SQL Server a efectos de
rendimiento.
Estoy de acuerdo en que el mantenimiento de claves foráneas es más eficiente
con claves más estrechas, y un entero de 4 bytes es más eficiente en este
caso que un varchar de 10 bytes. Sin embargo, no es necesario que la clave
foránea apunte a una clave primaria. El único requerimiento que SQL Server
impone es que la clave foránea apunte a un índice único, y esto se pyede
conseguir mediante una restricción única o un índice único sin más. Ya que
el tamaño de esta clave afecta a cada inserción y modificación de registros
en las tablas "hijas", el tamaño de esta clave es especialmente importante.
Por otro lado, una página de índice con una clave de 10 bytes podrá
almacenar, simplificando, unas 300 entradas por página (8000/(10+14)),
mientras que un índice con una clave de 4 bytes podría almacenar,
simplificando de nuevo, unas 400 entradas por página (8000/(4+14)). Esto
representa una diferencia considerable, que permitiría en algunas
operaciones una diferencia de rendimiento apreciable.
Otro caso distinto es la ejecución de JOIN, en cuyo caso el procesador debe
realizar una serie de comparaciones de valores extraídos de los campos de
enlace en ambas tablas. Con procesadores de 32 bits, cualquier valor mayor
de 4 bytes representa bien una comparación externa al procesador, o una
operación que requiere más de un ciclo de CPU, lo cual representa en
cualquier caso una merma de rendimiento. Sin embargo, en este caso, como en
el de claves foráneas, los valores almacenados en esos campos son
completamente irrelevantes para el usuario, y van a ser utilizados solamente
por SQL Server para validar entradas y para ejecutar enlaces, por lo que un
campo IDENTITY podría ser perfectamente válido.
Resumiendo, personalmente no tengo nada en contra con utilizar una clave
natural como clave primaria, pero para enlazar tablas prefiero utilizar un
campo lo más pequeño posible, y un entero de 4 bytes resulta perfecto
siempre que pueda utilizar hasta 2 mil millones de valores.
Para acabar esta larga nota (estoy en Seattle y acabo de terminar un cirso
de 6 días, así que me puedo permitir esta frivolidad), SQL Server no
garantiza que los valores devueltos por la función IDENTITY (o por la
propiedad IDENTITY) sean únicos, así que es necesario siempre crear un
índice único (o clave primaria o restricción única) en el mismo si se quiere
garantizar unicidad.
Para aquellos que no se crean que se puede crear claves foráneas que apunten
a campos distintos de la clave primaria, aquí va este script:
CREATE TABLE Gente (
DNI varchar(10) NOT NULL
PRIMARY KEY,
GenteID int NOT NULL
IDENTITY (1,1) UNIQUE,
Nombre varchar(50) NOT NULL
)
CREATE TABLE Facturas (
FacturaID int NOT NULL
IDENTITY (1,1) PRIMARY KEY,
ClaveFactura varchar(10) NOT NULL
UNIQUE,
GenteID int
REFERENCES Gente (GenteID),
Fecha smalldatetime
DEFAULT GETDATE(),
Total money
)
--
Fernando G. Guerrero
SQL Server MVP
QA plc., UK
PASS Spanish Group
www.sqlserverbyexample.com
www.callsql.com
www.qa.com
"Comparte lo que sabes, aprende lo que no sepas"
"Emilio Boucau" <bou...@towers.com> wrote in message
news:ukP2SbxMCHA.2420@tkmsftngp11...
Carlos Sacristán
fin y al cabo, ya que si Fernando dice: "[...]Resumiendo, personalmente no
tengo nada en contra con utilizar una clave
natural como clave primaria, pero para enlazar tablas prefiero utilizar un
campo lo más pequeño posible, y un entero de 4 bytes resulta perfecto
significa que te nos debes unas cervecitas :-D
P.D.: Fernando, la que me he ganao de Emilio, me la puedes descontar de
todas las que te debo. ;-)
jejejejejejeje
Emilio Boucau
lo de las cervecitas habra que hablarlo al momento de pagar ... a lo mejor
las paga Fernando por llegar tarde !
Fijate bien lo que dice Fernando sobre los DNIs ... habla de char(10) y yo
ya dije claramente que el DNI es un numero...
Con respecto a lo que Fernando dice de la performance interna a nivel CPU y
todo eso, estamos de acuerdo como dije antes, a lo mejor toma 1 microsegundo
contra 3 ... Honestamente, prefiero esa merma en la performance del proceso
y trabajar con un diseño como la gente. Si bien es el triple ... pero es el
triple de casi nada.
Ejemplo concreto y real, yo proceso datos en mi servidor en bases de 25 GB
con tablas que tienen FKs de 4 campos char(5) enlazados con una tabla madre
que tiene la misma clave como PK... y a lo mejor estoy usando los 3
microsegundos nombrados antes, pero la cosa vuela !
Y en tu cita textual a Fernando, se lee perfectamente lo que yo digo: 'usen
numeros (el DNI de mi analisis) para los joins !'
Mi analisis da que se puede usar un dato natural y no uno inventado para
hacer que esto funcione a la misma velocidad que con un dato secuencial.
Si en Bolivia esto se complica y se trona inadecuado, no lo se; yo vivo en
Argentina y ya tenemos suficientes problemas como para preocuparme que mi
diseño sirva en La Paz y en Kuala Lumpur, ya que estamos !
Mozo, mi cerveza con papas y mani, por favor ! Carlos nos invita a todos !
Un abrazo para todos !
PD: Fernando, no le descuentes nada de las que te debe a vos ... ;-)) Es
mas, yo le cargo una en mi cuenta !
Jorge Viñuales
Yo llevo mucho tiempo usando campos numéricos sencillos para enlazar tablas,
tal y como dice Fernando, incluso aunque en la tabla hubiese una clave
primaria natural válida de tipo alfanumérico de 10 o 20 caracteres.
Pero la experiencia me ha dicho, que si utilizo una clave numérica
inventada, donde podría utilizar la clave natural, termino necesitando
contínuamente hacer joins con la tabla de primarios solo para poder
presentar el campo que en realidad era clave natural. Y de poder usar solo
la tabla que me interesa a tener que montar un join con la tabla de claves
principales si que puede ir una gran diferencia en el rendimiento.
Por ejemplo. Una tabla de facturas y una de formas de pago. Si en la tabla
de formas de pago hago clave el propio nombre de la forma de pago, en lugar
de inventar un numérico, cuando estoy mostrando facturas, no necesito para
nada la tabla de formas de pago para que se vea cual es la forma de pago
usada en cada factura, puesto que directamente mi clave externa será
'Contado', 'Cheque', etc.
Saludos
"Fernando G. Guerrero" <fer...@guerrerog.org> escribió en el mensaje
news:#lxGg4cNCHA.1280@tkmsftngp13...
Miguel Egea
caso que comentas yo por ejemplo suelo 'desnormalizar'. ¿Por qué?, porque
una factura si la imprimo el año que viene tiene que decir lo mismo que si
la imprimo este, y el campo de forma de pago puede haberlo cambiado (su
descripcion) un usuario. En otros casos quizá esa desnormalización no sea
necesaria (ni conveniente). En fín que no hay verdades absolutas, pero hacer
un join (en tu caso) con una tabla que a lo sumo tendrá 25 a 50 registrso no
es mucho.
--
Un saludo
Miguel Egea
http://www.portalsql.com
Microsoft SQL-SERVER MVP
"Jorge Viñuales" <j...@able.es> escribió en el mensaje
news:#HLKjITSCHA.2500@tkmsftngp13...
Emilio Boucau
Jorge Viñuales
una muy buena situación para no permitir actualizaciones en cascada y por lo
tanto bloquear el nombre de la forma de pago (clave principal) para que no
te pase lo que has dicho.
(Ganaremos Emilio...)
"Miguel Egea" <mcgi...@airtel.net> escribió en el mensaje
news:#oIiO0TSCHA.2412@tkmsftngp13...
Eladio Rincón
si aprietas un poco más tendrás a uno más a tu favor. (Llevo algo más de 1
año trabajando sin Identities ). :-D
PD. Lo importante es que cada uno aporte sus experiencias, y así tendremos
todos los pros y contras.
--
Saludos;
Eladio Rincón
Pass Spanish Group
tvel...@torrevieja.infoville.net
"Emilio Boucau" <bou...@hotmail.com> escribió en el mensaje
news:u0dNvKUSCHA.2376@tkmsftngp11...
Miguel Egea
--
Un saludo
Miguel Egea
http://www.portalsql.com
Microsoft SQL-SERVER MVP
"Jorge Viñuales" <j...@able.es> escribió en el mensaje
news:u5#PiOVSCHA.2792@tkmsftngp09...
Emilio Boucau
impacto que tendra. Si un usuario tiene acceso a las tablas de valores
iniciales dele sistema (tipos de pago, moneda de pago, etc.) sabra lo que
esta haciendo ... O es un kamikaze o es un saboteador ... ;-)
Saludos !
"Miguel Egea" <mcgi...@airtel.net> wrote in message
news:#PSfv3VSCHA.4240@tkmsftngp08...