¿Es una buena idea usar una columna entera para almacenar los códigos postales de Estados Unidos en una base de datos?

StackOverflow https://stackoverflow.com/questions/893454

Pregunta

De primera vista, parecería que tengo dos opciones básicas para almacenar códigos postales en una tabla de base de datos:

  1. Texto (probablemente el más común), es decir, char(5) o varchar(9) para apoyar la extensión 4
  2. numérico, es decir, 32 bits entero

Tanto satisfaría los requisitos de los datos, si se supone que no hay preocupaciones internacionales. En el pasado hemos ido en general, sólo la ruta de texto, pero me preguntaba si alguien hace lo contrario? Sólo a partir de una comparación breve parece que el método de número entero tiene dos claras ventajas:

  • Es, por medio de su naturaleza, limita automáticamente a los valores numéricos solamente (mientras que sin la validación del estilo de texto podría almacenar cartas y tales que no es, que yo sepa, siempre válida en un código postal). Este no significa que podría / sería / debería renunciar a la validación de entrada del usuario como de costumbre, sin embargo!
  • Se necesita menos espacio, siendo 4 bytes (que debe haber un montón incluso para 9 dígitos códigos postales) en lugar de 5 o 9 bytes.

Además, parece que no estaría de salida de la pantalla mucho más. Es trivial palmada a un ToString() en un valor numérico, utilice la manipulación de cadenas simples para insertar un guión o el espacio o lo que sea para la ampliación 4, y utilizar el formato de cadenas para restaurar ceros a la izquierda.

¿Hay algo que pueda desalentar el uso de int como un tipo de datos para los Estados Unidos y sólo los códigos postales?

¿Fue útil?

Solución

Un código postal numérico es - en un pequeño camino - riesgo de error.

Los números deben significar algo numérico . códigos postales no sumar o restar o participan en las operaciones numéricas. 12309 -. 12345 no calcula la distancia desde el centro de Schenectady a mi barrio

Por supuesto, para los códigos postales, nadie está confundido. Sin embargo, para otros campos de números similares, puede ser confuso.

Dado que los códigos postales no son números - que acaba de pasar a ser codificado con un alfabeto restringido - Sugiero evitar un campo numérico. El ahorro de 1 byte no vale mucho. Y yo creo que eso significa es más importante que el byte.

Editar .

"En cuanto a los ceros a la izquierda ..." es mi punto. Los números no tienen ceros a la izquierda. La presencia de ceros iniciales significativas en los códigos postales es otra prueba de que no son numéricos.

Otros consejos

¿Usted va a almacenar siempre los códigos postales fuera de Estados Unidos? Canadá es de 6 caracteres con algunas letras. Normalmente yo sólo uso un campo de 10 caracteres. El espacio en disco es barato, tener que rehacer el modelo de datos no lo es.

Utilice una cadena con la validación. códigos postales pueden empezar por 0, de modo numérico no es un tipo adecuado. Además, esto se aplica perfectamente a los códigos postales internacionales (por ejemplo, Reino Unido, que es hasta 8 caracteres). En el caso poco probable de que los códigos postales son un cuello de botella, se podría limitar a 10 caracteres, pero echa un vistazo a su formatos de destino primero.

Éstos son la validación expresiones regulares para el Reino Unido, los Estados Unidos y Canadá.

Sí, puede almohadilla para obtener los ceros a la izquierda hacia atrás. Sin embargo, usted está teóricamente tirar información que pueda ayudar en caso de errores. Si alguien encuentra 1235 en la base de datos, es que originalmente 01235, o se ha perdido otro dígito?

La mejor práctica dice que se debe decir lo que quiere decir. Un código postal es un código, no un número. ¿Vas a añadir / restar / multiplicar / dividir códigos postales? Y desde un punto de vista práctico, es mucho más importante que se está excluyendo cremalleras prolongados.

Normalmente se usaría un tipo de datos no numéricos, tales como varchar lo que permitiría más tipos de código postal. Si usted está empeñado en que sólo permite 5 dígitos [XXXXX] o [9 dígitos XXXXX-XXXX] códigos postales, se puede entonces utilizar un char (5) o char (10), pero yo no lo recomendaría. Varchar es la opción más segura y más sana.

Edit: También debe tenerse en cuenta que si usted no planea en hacer cálculos numéricos en el campo, no se debe utilizar un tipo de datos numérico. Código postal es un no es un número en el sentido de que se añaden o se quitan en contra de ella. Es simplemente una cadena que pasa a estar compuesto por lo general de los números, por lo que debe abstenerse de utilizar los tipos de datos numéricos para ello.

Desde un punto de vista técnico, algunos puntos planteados aquí son bastante trivial. Yo trabajo con la limpieza de datos de direcciones en un todos los días base - en particular los datos de direcciones limpieza de todo el mundo. No es una tarea trivial por cualquier tramo de la imaginación. Cuando se trata de los códigos postales, que podría guardarlas como un entero, aunque puede que no sea "semánticamente" correcta. El hecho es que los datos son de una forma numérica o no, estrictamente hablando es considerado numérico de valor.

Sin embargo, el inconveniente muy real de almacenarlas como tipos numéricos es que si no se pierden la capacidad de ver fácilmente si se equivoca al introducir los datos (es decir, tiene valores perdidos) o si el sistema elimina los ceros iniciales que conducen a operaciones costosas validar los códigos postales potencialmente no válidos que eran de otra forma correcta.

También es muy difícil obligar al usuario introducir datos correctos si una de las consecuencias es un retraso de negocio. Los usuarios a menudo no tienen la paciencia para introducir los datos correctos si no es inmediatamente obvio. Usando una expresión regular es una forma de garantizar datos correctos, sin embargo, si el usuario introduce un valor que no se conforma y que están visualiza un error, es posible que simplemente omiten este valor en conjunto o entrar en algo que se ajusta, pero es de otra manera incorrecta. Un ejemplo [el uso de códigos postales canadienses] es que a menudo se ve A0A 0A0 emitida, ésta no es válida, pero se ajusta a la expresión regular para los códigos postales canadienses. Más a menudo que no, esto se ponen los usuarios que se ven obligados a proporcionar un código postal, pero, o no saben lo que es o no tienen todos de la misma correcta.

Una sugerencia es para validar la totalidad de la entrada como una unidad validar que el código postal es correcta si se compara con el resto de la dirección. Si es incorrecto, a continuación, que ofrecen alternativas códigos postales válidos para la dirección hará que sea más fácil para ellos de entrada de datos válidos. Del mismo modo, si el código postal es correcta para la dirección de la calle, pero el número de la calle cae fuera del dominio de ese código postal, a continuación, ofrecer números de las calles alternas para ese / combinación de código postal calle.

A menos que tenga un requisito de negocio para realizar cálculos matemáticos sobre los datos del código postal, no tiene sentido en el uso de un INT. Usted es mayor de ingeniería.

Espero que esta ayuda,

Bill

No, porque

  • Nunca haces funciones matemáticas en el código postal
  • Podría contener guiones
  • Podría comenzar con 0
  • valores NULL veces interpretados como cero en el caso de tipos escalares como número entero (por ejemplo, cuando se exporta los datos de alguna manera)
  • código postal, incluso si es un número, es una designación de un área, es decir, se trata de un nombre en lugar de una cantidad numérica de nada

código postal es realmente un espacio de nombre codificado, si se piensa en ello. Tradicionalmente dígitos, pero también un guión y mayúsculas:

"10022-SHOE"

http://www.saksfifthavenue.com/main/10022-shoe.jsp

Siendo realistas, una gran cantidad de aplicaciones de negocios no tiene que apoyar este caso extremo, incluso si es válido.

Entero es agradable, pero sólo funciona en los EE.UU., por lo que la mayoría de las personas no lo hacen. Por lo general, sólo tiene que utilizar un varchar (20) o menos. Algo excesivo para cualquier configuración regional.

Si se va a utilizar un número entero de cremalleras de Estados Unidos, que se quiere multiplicar el papel principal en 10.000 y añadir la 4. La codificación en la base de datos no tiene nada que ver con la validación de entrada. Siempre se puede exigir la entrada sea válida o no, pero el almacenamiento es cuestión de cuánto usted piensa que sus necesidades o el USPS va a cambiar. (Pista: sus requerimientos cambio.)

sabido recientemente que en Ruby una de las razones que se quiere evitar esto se debe a que hay algunos códigos postales que comienzan con ceros a la izquierda, que, si almacenan como en enteros serán automáticamente convertidos en octal.

los documentos :

  

Puede utilizar un prefijo especial para escribir los números en decimal, hexadecimal, octal o binario. Para los números decimales usar un prefijo de 0d, para los números hexadecimales utilizan un prefijo de 0x, para los números octales utilizan un prefijo de 0 o 0o ...

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top