¿Tiene algún inconveniente para almacenar un número entero como una cadena en una base de datos?

Question

Tengo valores de identificación para los productos que necesito almacenar. En este momento, todos son enteros, pero no estoy seguro de si el proveedor de datos en el futuro introducirá letras o símbolos en esa mezcla, por lo que estoy debatiendo si almacenarlo ahora como un entero o una cadena.

¿Hay algún rendimiento u otras desventajas para guardar los valores como cadenas?

Answer 1

A menos que realmente necesite las características de un entero (es decir, la capacidad de hacer aritmética), entonces es probable que sea mejor para usted almacenar los ID de productos como cadenas. Nunca tendrá que hacer algo como agregar dos ID de productos juntos o calcular el promedio de un grupo de ID de productos, por lo que no es necesario un tipo numérico real.

Es poco probable que el almacenamiento de identificadores de productos como cadenas cause una diferencia mensurable en el rendimiento. Si bien habrá un ligero aumento en el tamaño de almacenamiento, es probable que el tamaño de una cadena de ID de producto sea mucho más pequeño que los datos en el resto de la fila de su base de datos.

Almacenar los ID de productos como cadenas hoy le ahorrará mucho dolor en el futuro si el proveedor de datos decide comenzar a utilizar caracteres alfabéticos o de símbolos. No hay un inconveniente real.

Answer 2

Los enteros son más eficientes desde el punto de vista del almacenamiento y el rendimiento. Sin embargo, si hay una posibilidad remota de que se introduzcan caracteres alfa, entonces debe usar una cadena. En mi opinión, es probable que los beneficios de eficiencia y rendimiento sean insignificantes, mientras que el tiempo necesario para modificar su código puede no serlo.

Answer 3

No estoy seguro de qué tan buenas son las bases de datos para comparar si una cadena es mayor que otra, como puede ser con enteros. Pruebe una consulta como esta:

SELECT * FROM my_table WHERE integer_as_string > '100'; 

Answer 4

Realmente depende de qué tipo de identificación está hablando. Si se trata de un código como un número de teléfono, en realidad sería mejor usar un varchar para la identificación y luego tener su propia identificación para ser una serie para la base de datos y usarla para la clave principal. En un caso donde el entero no tiene valor numérico, generalmente se prefieren varchar.

Answer 5

como respondida en Integer vs String in database

En mi país, después de los códigos también son siempre 4 dígitos. Pero el primer dígito puede ser cero.

Si almacena "0700" como un entero, se puede obtener una gran cantidad de problemas:

Puede leerse como un valor octal Si se lee correctamente como un valor decimal, que se excita en "700" Cuando obtiene el valor "700", debe recordar agregar cero I 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 cadenas reales, 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é tal para almacenar cuántos archivos hay en un torrent? ¿Entero o cadena?

Eso es claramente un número entero.

Si la ID alguna vez comienza con cero, guárdela como en interger.

Answer 6

NO considere el rendimiento. Considera el significado.

ID "números" no son numéricos, excepto que están escritos con un alfabeto de todos los dígitos.

Si tengo el número de parte 12 y el número de parte 14, ¿cuál es la diferencia entre los dos? ¿Es significativo el número de parte 2 o -2? No.

Los números de parte (y cualquier cosa que no tenga unidades de medida) no son "numéricos". Son solo cadenas de dígitos.

Códigos postales en EE. UU., Por ejemplo. Números de teléfono. Números de seguridad social. Estos no son números. En mi ciudad, la diferencia entre el código postal 12345 y 12309 no es la distancia desde mi casa al centro.

No confunde números - con unidades - donde las sumas y las diferencias significan algo con cadenas de dígitos sin sumas ni diferencias.

Los números de identificación de las piezas son, correctamente, las cadenas. No enteros. Nunca serán enteros porque no tienen sumas, diferencias o promedios.

Answer 7

El espacio que ocuparía un entero sería mucho menos que una cadena. Por ejemplo 2^32-1 = 4.294.967.295. Esto tomaría 10 bytes para almacenar, mientras que el entero tomaría 4 bytes para almacenar. Para una sola entrada, esto no es mucho espacio, pero cuando comienzas en millones ... Como muchas otras publicaciones sugieren que hay varios otros asuntos a considerar, pero esto es un inconveniente de la representación de cadenas.

Answer 8

Acabo de pasar el último año lidiando con una base de datos que tiene casi todos los ID como cadenas, algunos con dígitos solamente y otros mixtos. Estos son los problemas:

1. Espacio de ID extremadamente restringido. Una identificación de 4 caracteres (solo dígitos) tiene capacidad para 10,000 valores únicos. Un número de 4 bytes tiene capacidad para más de 4 mil millones.
2. Cobertura de espacio de ID impredecible. Una vez que las identificaciones comienzan a incluir dígitos que no son dígitos, resulta difícil predecir dónde puede crear nuevas identificaciones sin colisiones.
3. Problemas de conversión y visualización en determinadas circunstancias, al crear scripts o al exportar, por ejemplo. Si el ID se interpreta como un número y hay un cero inicial, el ID se altera.
4. Problemas de clasificación. No puede confiar en que el orden natural sea útil.

Por supuesto, si te quedas sin ID o si no sabes cómo crear nuevos ID, tu aplicación está muerta. Sugiero que, si no puede controlar el formato de sus ID entrantes, debe crear sus propios ID (numéricos) y relacionar el ID proporcionado por el usuario con eso. Luego puede asegurarse de que su propia identificación sea confiable y única (y numérica), pero proporcione una identificación visible por el usuario que pueda tener el formato que desee el usuario, y que ni siquiera tenga que ser exclusivo en toda la aplicación. Esto es más trabajo, pero si hubieras pasado por lo que tengo, sabrías qué camino tomar.

Anil G

Answer 9

1. Usted no será capaz de hacer comparaciones correctamente. "... donde x> 500" no es lo mismo que "...donde x> '500'", porque '500'> '100000' sabia cadena
2. rendimiento que sería un éxito especialmente si se utiliza índices como índices enteros son mucho más rápidos que los índices de cadenas.

Por otro Depende de su situación. Si tiene la intención de almacenar algo así como números de teléfono o números de inscripción de estudiantes, tiene mucho sentido usar cadenas.

Answer 10

Mejor use ID independiente y agregue ID de cadena si es necesario: si hay una empresa indicador que debe incluir, ¿por qué hacerlo identificación del sistema?

Main drawbac KS:

1. operaciones de enteros y la indexación siempre muestran un mejor rendimiento en grandes escalas de datos (más de 1k filas de una tabla, por no hablar de tablas relacionadas)

2. Vas a tener que hacer adicional comprueba para restringir valores numéricos únicos en una columna: estos pueden ser expresiones regulares, ya sea en el lado del cliente o de la base de datos. De todos modos, tendrás que garantizar de alguna manera que en realidad hay un número entero.

3. y va a crear capa de contexto adicional para que los desarrolladores saben, y en cualquier caso siempre alguien va a estropear esto :)