database - programacion - tipos de datos int
Entero vs cadena en la base de datos (15)
¿Es ''0000'' un código postal? ¿Es distinto de ''0''?
Si siempre es un número de cuatro dígitos, siempre lo almacenaría como 4 dígitos, y eso apunta a mantenerlo como una cadena.
Al definir tipos de datos en una base de datos, siempre he tenido un problema al elegir si usar enteros o cadenas para almacenar ciertos datos ''numéricos''.
Supongamos que estoy creando Another Yet Address y que hay un campo de código postal. Siempre que los códigos postales sean siempre un número de 4 dígitos, ¿con qué tipo de datos lo almaceno? ¿Entero o cadena? Técnicamente es un número entero, pero no estoy haciendo ningún tipo de cálculos, solo lo estoy escupiendo en una tabla. ¿Cambiaría su opinión si quiero ordenar la tabla por código postal?
Ahora, no soy estúpido. Reconozco una necesidad válida de enteros, como visitas a la página y usuarios únicos o usuarios con sesión iniciada y usuarios invitados. ¿Pero qué hay para almacenar cuántos archivos hay en un torrente? ¿Entero o cadena?
El código postal no es un número: es un código o identificador. Lo mismo se aplica a los números de teléfono.
El número de archivos en un torrente es un número entero.
No menos importante, en este caso, puede crear una CHECK CONSTRAINT LIKE ''[09][09][09][09]'' para mantener la información correcta en el nivel de la base de datos.
El determinante crítico, iho, es si la aplicación necesitará hacer cálculos aritméticos numéricos en los valores; si no, la única razón para usar enteros es reducir los requisitos de almacenamiento (que "Puede" ser importante para el rendimiento en un entorno crítico). aplicación - al reducir el ancho de un índice de tabla para aumentar el rendimiento del índice, por ejemplo), pero por lo demás, generalmente no es importante ...
Si no hay necesidad de hacer aritmética con los valores, entonces una cadena es la mejor.
En lo que respecta a los códigos postales, este es un código postal típico del Reino Unido:
EC2R 6PK
En la universidad, mi profesor de bases de datos me dijo algo que se me ha quedado grabado y que aún tiene más de 15 años después:
Si realiza aritmética en él, almacénelo como un número. De lo contrario, es una cadena.
Francamente, no creo que puedas equivocarte con ese consejo.
Obviamente, no realizas operaciones aritméticas en los códigos postales, por lo tanto, son cadenas.
En mi país, los códigos postales también son siempre de 4 dígitos. Pero el primer dígito puede ser cero.
Si almacena "0700" como un número entero, puede tener muchos problemas:
- Puede leerse como un valor octal
- Si se lee correctamente como un valor decimal, se convierte en "700"
- Cuando obtiene el valor "700", debe recordar agregar el cero
- Si no agrega el cero, más adelante, ¿cómo sabrá si "700" es "0700", o si alguien escribió mal "7100"?
Técnicamente, nuestros códigos postales son en realidad cadenas, incluso si siempre son 4 dígitos.
Puede almacenarlos como enteros, para ahorrar espacio. Pero recuerde que este es un simple truco DB, y tenga cuidado con los ceros a la izquierda.
¿Pero qué hay para almacenar cuántos archivos hay en un torrente? ¿Entero o cadena?
Eso es claramente un número entero.
Esta es una cuestión de semántica. Está intentando decidir el tipo de datos apropiado para el almacenamiento, lo que puede ser una pregunta difícil. La mejor regla general es almacenar sus datos como enteros si necesita usar los datos como un entero.
En otras palabras, dado que nunca usará un código postal como número, no tiene sentido almacenarlo como uno solo. No importa cómo se ve la información, importa lo que sea . ¿Es un código postal un número? No, es una cadena de caracteres que está compuesta de personajes totalmente numéricos. Por lo tanto, un código postal se almacena mejor como una cadena.
Los códigos postales son cadenas. Para algunos comités, esas cadenas pueden consistir en un solo dígito numérico, pero eso no los convierte en enteros. Y tarde o temprano su sistema potal se quedará sin dígitos y decidirá comenzar a usar letras también. Si su base de datos usa números enteros para el campo de código postal, estará en un profundo doo-doo.
En pocas palabras: si no hace cálculos aritméticos, probablemente no sea realmente un número.
No uso un tipo de datos numéricos a menos que espere hacer cálculos matemáticos sobre los datos. Por qué arriesgarse a encontrar un problema en el futuro por algo de lo que estaba "seguro" siempre sería un número en el que alguien decide poner un carácter no numérico.
Si no va a hacer cálculos en él, conviértalo en una cadena.
No veo ningún problema para almacenar un código postal como un número, incluso si no espera realizar operaciones matemáticas en él.
En nuestro almacén de datos corporativo, somos los destinatarios de los datos de muchos sistemas heredados. Como resultado, vemos una gran cantidad de datos basura que se utilizan.
Consideremos nuestro caso donde tenemos un identificador geográfico que es un valor "numérico" de 4 dígitos lleno de cero. Este campo se usa a menudo para unir tablas.
Tomaría uno de dos enfoques: 1) declarar la columna como un campo de caracteres de longitud 4 y agregar una RESTRICCIÓN COMO ''[09] [09] [09] [09]'' 2) definirla como una longitud numérica 4 y, si los usuarios lo desean, formatee el valor CUANDO EXHIBA solo.
Approach numeric 1 le ahorra la molestia de formatear constantemente, lo que no es gran cosa, pero si a menudo filtra e incluso indexa / une en la columna, consideraría decir que estamos fuera de la opción # 2.
Una tercera razón es que mi experiencia es que las personas son simplemente flojas cuando se trata de agregar restricciones a una base de datos o que son ignorantes. Creo que es más pereza, personalmente. Encuentro que las restricciones que existen se aplican principalmente como ediciones en la aplicación que originalmente captura los datos y que las ediciones no se aplican uniformemente.
Como resultado, nuestro almacén de datos termina recibiendo todo tipo de variaciones, incluido el prellenado incoherente con ceros o la justificación del valor.
Cuando define algo como INTEGER, obtiene automáticamente un almacenamiento más eficiente, esp. al indexar en la columna, y editar lo que todos entienden y es más probable que los diseñadores de bases de datos de varias habilidades apliquen sistemáticamente en todos los sistemas heredados.
No tengo ningún problema con la opción n. ° 1, con la excepción de usar el campo en un índice y mi preocupación sobre el enfoque de una vez que acepta un campo como apha numérico, las personas tienden a arrojar más basura en él.
Tomemos como ejemplo nuestro identificador de empleados de Peoplesoft. Alguien decidió agregar una "X" delante de un "número" lleno de cero de 6 caracteres del empleado para designar que el empleado es un contratista. Esto viola una práctica personal mía al no combinar piezas separadas de información en un solo campo. Esto causó todo tipo de problemas de inconsistencia en varios sistemas. Si este campo fuera numérico, nadie hubiera intentado hacer eso.
¿Comentarios?
Para un código postal, elegiría una cadena. No es intrínsecamente un número entero. Es solo un identificador de algo y podría haber sido una serie de cuatro personajes.
En cuanto a la cantidad de archivos dentro de un torrente, debería ser un número entero.
Siempre uso la siguiente regla:
Si planea realizar cálculos matemáticos en él (agregar / restar / etc.), conviértalo en un entero u otro tipo de datos numéricos.
Si no planea realizar ningún tipo de cálculo matemático en el campo, guárdelo como una cadena.
En el caso de los códigos postales, nunca debe tener un momento en el que necesite agregar a un código postal, o restar, o multiplicar dos códigos postales juntos. Las funciones matemáticas generalmente no se usan en los códigos postales porque se usan como identificadores y no como cantidades. Por lo tanto, debe almacenar su código postal como un tipo de datos de cadena
Somtimes "siempre" significa "para el próximo mes". No contaría con códigos de 4 dígitos que no se vuelven alfanuméricos dentro de la duración de mi responsabilidad.
Algunos dialectos de SQL admiten un tipo de datos que es como NÚMERO (4). Esto funciona como una cadena de caracteres, pero el alfabeto es de 0 a 9.
También es bueno recordar que no todos los códigos postales en todos los counrties son solo números. El hecho de que no tenga ningún destinatario en Canadá en este momento no significa que no tenga ninguno. Siempre he seguido la regla, si quiere hacer cálculos matemáticos guárdelo en un tipo numérico, si es solo un código (códigos postales, teléfonos, SSN, número de partidas, etc.) entonces lo almaceno como una cadena. Lo que desea evitar es una conversión innecesaria de los datos en otro formato cada vez que lo active (por ejemplo, código para agregar los ceros iniciales si almacena el código postal como un número o código para convertir una cadena en un número para las callaciones) ) Estas pueden ser operaciones costosas si necesita hacerlas repetidamente, especialmente cuando las tablas son grandes y termina teniendo que hacer la conversión en la cláusula where. Es mucho mejor almacenar los datos de la manera que necesita usarlos.
en mi opinión, para los códigos postales debes usar cadenas, porque puedes tener códigos postales que tengan cero (09100) y si usas números enteros sería 9100: la clasificación no es un problema, porque todavía hay un orden alfabético ('' 09100 ''viene antes de'' 09101 ''). Para almacenar números de archivo, esperaría un interger, por lo que no tiene ningún problema para aumentar / disminuir su número. ¡Así que el entero frente a las cadenas depende del uso que hagas!
Siempre es importante comprender la semántica de los datos con los que está trabajando. Déjame explicarlo en el ejemplo.
Considere que desea almacenar PIN en su base de datos. Para responder a qué tipo de datos debe usar, primero debe responder qué PIN realmente significa.
Si realmente es un número como su nombre indica realmente, entonces no veo ningún motivo por el cual no deba representarse como un número entero.
Algunas personas podrían argumentar que no se puede distinguir entre 0001 y 01. Evidentemente, no consideran PIN un número y si están trabajando con esa semántica deberían usar una cadena.
Nota: Si la longitud del PIN se reparara, digamos 4 dígitos, podrían usar números enteros porque cualquier número siempre estará lleno de ceros a la izquierda y tendrán exactamente el mismo valor (0001 será igual a 01), pero estas restricciones de longitud fija son típico de los números para evitar entradas incorrectas.
Si la semántica indica claramente que PIN es un número, es decir, que PIN 0001 es exactamente igual que PIN 01, usaría una representación entera.
Por lo tanto, en su caso, es importante comprender la semántica del código postal . Esa semántica puede variar en diferentes países (o incluso cambiar con el tiempo), por lo que también es importante que desee utilizar. Para cubrir todo tipo de códigos postales e incluso posibles cambios, consideraría utilizar un tipo de datos más abstracto o solo una cadena (creo que ya hay una semántica que contiene más caracteres que solo dígitos).
No recomendaría seguir reglas simplificadas como la de las operaciones aritméticas sobre la representación de datos. Si no desea realizar operaciones matemáticas con datos ahora, no significa que no querrá a veces en el futuro.
Usted tiene datos y desea almacenarlos, representarlos de alguna manera, simplemente piense en qué es con lo que está trabajando.