9 respuestas en este tema

[cram]

Hace unos años ví un colega que en una base de datos había declarado un número de documento como entero largo (big int, long int, no recuerdo, menos el nombre ya que no manejo ese motor).

 

El tema es precisamente ese. Recuerdo que en una clase de -creo- base de datos en la facultad, decía el profesor: "si no usarás el dato para cálculo matemático, declararlo aunque esté compuesto solo por números como una cadena de caracteres". Y esto es algo simple.

En otras palabras, no significa que un dato deba ser declarado de tipo numérico cuando está compuesto únicamente por números. Sino importa el tratamiento que tendrá al ser recuperado y como se obtiene para ser almacenado en la base de datos.

Guardar un dato en la menor cantidad de pasos es muy imortante. Además, si se tratara de un número por más grande que fuere, pero que no se usará para cálculos matemáticos, no lo declararíamos como un tipo numérico gigante, sino como una cadena, ya que lo que haremos es solo mostrarlo o a lo sumo concatenarlo.

 

La verdad, que no entiendo cual es la ventaja de declararlo de esta manera, pues hay que pasarlo a cadena para llevarlo a un campo de edición.

 

Aclaro que en Argentina, los números de documento nacional de identidad tienen ocho cifras, un número de CUIT (Código Único de Identificación Tributaria) tiene once cifras.

 

Nadie suma números de documentos u obtiene un promedio...

 

Saludos

 

[Delphius]

El tema del DNI es que éste es una clave candidata. Y como tal merece considerar en análisis si se va a considerar como una clave primaria.

Por regla general todos los motores de base de datos tienen mejor rendimiento cuando la clave es de tipo numérico. Los motores prefieren claves numéricas a las alfanuméricas; aunque ahora se está haciendo "de modé" emplar como clave los GUID.

Y si se va aplicar un índice sobre dicho campo, con más razón es preferible que se mantenga el tipo numérico.

No se va a sumar, o hacer alguna operación matemática con dicho campo (no resiste el menor análisis ni tiene sentido alguno hacer algo como eso) pero si internamente el motor aplicará las técnicas de indexado sobre dicho campo y se gana mucho que este sea numérico.

 

Ahora bien, haberlo definido como un large int quizá sea un pelin pasado; a menos que se considere también la posibilidad que en dicha base de datos se almacenara toda la población mundial

 

Podríamos poner en debate el tema si se tomara bajo análisis o consideración otros campos que no tengan la finalidad o pudieran ser claves candidatas.

 

Saludos,

[cram]

Así es Delphius, el Número de DNI es una clave candidata. Pero no siempre es usadas como clave primaria por varias razones, dado que al menos, en Argentina, no todos poseen el DNI y otros usan otro tipo de documentación. Extraño pero cierto. Por lo que la cllave sería la concatenación del tipo de documento con el número de documento que termina por "destruir" cualquier avance en el uso de un campo con orden establecido.

Particularmente no uso al DNI como clave primaria, menos consideraría tener a ese campo ordenado, ya que la mayor parte de las búsquedas son usando otro campo, como apellido o nombre, o ambos. En la base de datos que desarrollé recientemente uso como acceso unívoco una clave de cliente que es en definitiva su ID dentro de un EAN-13, así es posible encontrarlo usando un scanner.

 

Es bueno saber que los motores se "sienten mejor" con las claves numéricas.

 

Saludos

[genriquez]

Definitivamente para la base de datos es mejor tener las claves primarias como numéricos, pero por otro lado, esto es realmente bueno en aquellas tablas que poseen millones de registros, la diferencia entre el desempeño entre un índice conformado por números y otro por caracteres para tablas de unos cuantos registros es insignificante, yo hice la prueba con postgres y tablas de 300.000 registros y no hay diferencia perceptible.

 

Lo que alguna vez me explicaron y nunca lo he validado es en la conformación de llaves compuestas, donde un campo es numérico y otro de carácter,  decían que tomaba más tiempo,  la verdad fue hace mucho tiempo y con bases de datos arcaicas, no se si será válido todavía.

 

En mi práctica, siempre utilizo la máxima que si no se realizarán operaciones matemáticas, utilizo caracteres,  más por la flexibilidad que puede obtenerse a futuro,  ej. adicionar un "-1" raya uno al final de código, o cosas así.   Excepto si la tabla contendrá un número considerable de registros, allí si se evalúa la posibilidad de crear la clave con números.

 

Saludos.

[Delphius]

 

Lo que alguna vez me explicaron y nunca lo he validado es en la conformación de llaves compuestas, donde un campo es numérico y otro de carácter,  decían que tomaba más tiempo,  la verdad fue hace mucho tiempo y con bases de datos arcaicas, no se si será válido todavía.

 

No te sabría decir si es lo mismo en todos los motores, pero al menos Firebird dejó documentado en su Firebird Book que una clave compuesta no tiene el mejor rendimiento. Y hasta recuerdo haber leído que en lo posible deben evitarse.

 

Aunque es de esperar, y hasta algo obvio, que en general en todas las bases de datos una clave compuesta no tiene el mejor rendimiento comparado con una clave primaria simple.

 

Saludos,

[Delphius]

Así es Delphius, el Número de DNI es una clave candidata. Pero no siempre es usadas como clave primaria por varias razones, dado que al menos, en Argentina, no todos poseen el DNI y otros usan otro tipo de documentación. Extraño pero cierto. Por lo que la cllave sería la concatenación del tipo de documento con el número de documento que termina por "destruir" cualquier avance en el uso de un campo con orden establecido.

Particularmente no uso al DNI como clave primaria, menos consideraría tener a ese campo ordenado, ya que la mayor parte de las búsquedas son usando otro campo, como apellido o nombre, o ambos. En la base de datos que desarrollé recientemente uso como acceso unívoco una clave de cliente que es en definitiva su ID dentro de un EAN-13, así es posible encontrarlo usando un scanner.

 

Es bueno saber que los motores se "sienten mejor" con las claves numéricas.

 

Saludos

 

En teoría no existe colisión entre el DNI y las Libretas Cívicas y las de Enrolamiento.

Aunque si es cierto que hay todo un descontrol con el tema de los DNIs y el Gobierno Nacional, como los Provinciales, debe sentarse y acabar con esto. Hay DNIs mellizos en varios lados. En el Blog de Investigación Eliminando Variables junto con la colaboración de otros periodistas agrupados bajo el nombre REx Aluminio han aportado material que se fue recolectando desde hace unos años.

Generalmente esto mellizos se detectan cuando son tiempos de elecciones, y para truchar firmas, facturas, etc. que luego desaparecen bajo el radar.

 

Ahora bien, por esto último a pesar de existir un conflicto de unicidad la posibilidad en términos prácticos es algo baja.

 

A pesar de ello, comparto también tu opinión de que no sea clave primaria y dejarla como un campo más. De esta forma es útil luego disponer de un índice, ya que puede ayudar a realizar búsquedas sobre este campo. No comparto del todo que lo normal sea buscar por el nombre y/o el apellido, hay cientos de ejemplos en donde una búsqueda se hace basado en el DNI. ¡Para eso fue inventado!

 

Saludos,

[Agustin Ortu]

Comparto con Delphius en practicamente todo

 

cram, Por algo implemente esto, y realmente a la gente le encanta. Yo tambien creo que las busquedas por estos numeros son muy utiles y los usuarios saben valorarlo

 

En particular yo lo dejo como string tanto el DNI como el CUIT; a pesar de que sea todo numeros, la naturaleza mas correcta para este dato en particular, en estas reglas de negocio, indican que lo mejor es un string

 

Por ejemplo, con un string podes realizar filtros parciales (tipo LIKE) o busquedas incrementales (F3, F3, F3, vas avanzando al siguiente); y si por supuesto que es posible convertir la columna dado el momento pero eso tiene bastante mas costo

 

En el unico caso que realmente ayuda tener el Integer, es para las búsquedas exactas, ahi si mejora la performance, aunque tambien creo que lo que apunta genriquez es cierto, hay que ver si esa performance es realmente notable en este orden de registros

 

Tambien aclaro que no lo uso como clave candidata, ni primaria, ni nada, ya que para ese proposito sigo pensando que las claves artificiales son las mejores; de ninguna manera me puedo permitir identificar univocamente a un registro con un valor que ingresa el usuario

 

Aun asi, mantengo un indice de tipo "unique" para asegurarme que no haya duplicados; en este caso una cosa son las reglas de negocio, y da igual si es fradulento o un error del gobierno, o lo que sea; pero tambien existen los errores de tipeo y por eso siempre me parece que es una buena idea que la BD solita se encarge de asegurar que no haya repetidos

 

Saludos

Editado por Agustin Ortu, 31 marzo 2016 - 09:28 .

[genriquez]

Aquí me entra una duda y creo que alguna vez la discutimos en otro punto en este foro,   que ventajas tienen las llaves artificiales ante las que llaves que digita el usuario?  al fin y al cabo hay que definirlas como unique.

 

Saludos.

[cram]

Comparto con Delphius en practicamente todo

 

cram, Por algo implemente esto, y realmente a la gente le encanta. Yo tambien creo que las busquedas por estos numeros son muy utiles y los usuarios saben valorarlo

 

En particular yo lo dejo como string tanto el DNI como el CUIT; a pesar de que sea todo numeros, la naturaleza mas correcta para este dato en particular, en estas reglas de negocio, indican que lo mejor es un string

 

Por ejemplo, con un string podes realizar filtros parciales (tipo LIKE) o busquedas incrementales (F3, F3, F3, vas avanzando al siguiente); y si por supuesto que es posible convertir la columna dado el momento pero eso tiene bastante mas costo

 

En el unico caso que realmente ayuda tener el Integer, es para las búsquedas exactas, ahi si mejora la performance, aunque tambien creo que lo que apunta genriquez es cierto, hay que ver si esa performance es realmente notable en este orden de registros

 

Tambien aclaro que no lo uso como clave candidata, ni primaria, ni nada, ya que para ese proposito sigo pensando que las claves artificiales son las mejores; de ninguna manera me puedo permitir identificar univocamente a un registro con un valor que ingresa el usuario

 

Aun asi, mantengo un indice de tipo "unique" para asegurarme que no haya duplicados; en este caso una cosa son las reglas de negocio, y da igual si es fradulento o un error del gobierno, o lo que sea; pero tambien existen los errores de tipeo y por eso siempre me parece que es una buena idea que la BD solita se encarge de asegurar que no haya repetidos

 

Saludos

 

¿eh?...

 

1 - digo 5

2 - digo 6

3 - claro, como dice el segundo: 5

 

Es precisamente lo que expuse en el principio. No usar tipos numéricos para estos campos.

 

Lo que dije en un principio al iniciar el tema es que uso tipo char, por ejemplo para el DNI, que en realidad le llamo Nro_Doc, Char(8).

Y aclaro, es precisamente por lo que dices, da más flexibilidad al momento de trabajar con el dato como está, ya sea búsquedas incrementales (mala palabra en algunos casos) o para evitar el uso de conversiones internas, o sea en el programa.

 

Ya que tocaron el tema de perder algo de tiempo en el proceso, definir como char(8) lleva un tiempo para aquellos casos en que el Nro_Doc, tenga -supongamos- cuatro dígitos, (cosa que es imposible), dado que el motor llena con blancos hasta llegar a ocho (8) de longitud, pero se usa char debido a que es muy poco probable una longitud diferente de 8, por lo que se ahorra un pequeño espacio al no definir como varchar(8).

 

En realidad son sutilezas, pero en cuanto a definirlo como cadena y no como número, no tanto, ya que el ahorro de trabajo es suficiente como para adoptar esta alternativa.

 

Suelo usar esta regla:

- el campo no será usado en operaciones matemáticas: char o varchar.

  - el campo casi siempre tiene una longitud, lo defino como char.

  - el campo es de longitud considerable y muy variable, uso varchar.

- cuando quiero acotar un valor numérico uso numeric, caso contrario integer o smallint, o algún otro.

 

Por ejemplo, en el caso moneda, suelo usar numeric(9,2) y no un tipo float o double.

 

Y por sobre todo a cada columna la defino con un dominio, no uso los tipos básicos, aunque tenga que crear un dominio de tipo smallint, sin restricciones, ni default, ni nada.

 

Saludos

 

 

Saludos.

Editado por cram, 31 marzo 2016 - 09:12 .

[cram]

Otra costumbre que ví, y supongo alguien tendrá alguna razón, pero no la veo; es aquella de definir todo como por ejemmplo, varchar(60) a todas las variables de tipo cadena o a casi todas, sea nombre, apellido, domicilio, número telefónico, etc.

 

Suelo tomarme el trabajo de definirlo con el máximo permitido, así es posible implementar reglas sin tantas complicaciones, por ejemplo, al nombre y apellido no los considero juntos, sino separados y luego los uno en una vista, APELLIDO || ', ' || NOMBRE o NOMBRE || ' ' || APELLIDO. y a cada uno de doy una longitud de 30, por las dudas para aquellos casos de apellidos dobles o personas con hasta tres nombres. En realidad esto es preferible aclarar al operador. Si llega a utilizar cerca de cincuenta caracteres para el nombre completo, los listados podrían aparecer cortados, y por otra parte, no conviene reservar espacio solo por las dudas (esas por las dudas de 2%).

 

Todo un caso.