MySQL - cómo código postal del panel frontal con "0"?

Question

En mi base de datos MySQL InnoDB, tengo datos sucios de código postal que quiero limpiar.

Los datos del código postal limpio son cuando tengo los 5 dígitos para un código postal (por ejemplo, "90210").

Pero por alguna razón, me di cuenta en mi base de datos que para los códigos postales que comienzan con un "0", el 0 se ha eliminado.

Así "Holtsville, Nueva York" con el código postal "00544" se almacena en mi base de datos como "544"

y

"Dedham, MA" con el código postal "02026" se almacena en mi base de datos como "2026".

¿Qué SQL puedo ejecutar en el panel frontal "0" a cualquier código postal que no tenga 5 dígitos de longitud? Es decir, si el código postal tiene 3 dígitos de longitud, la almohadilla frontal "00". Si el código postal tiene 4 dígitos, la almohadilla frontal solo "0".

ACTUALIZACIÓN:

Acabo de cambiar el código postal de ser el tipo de datos VARCHAR (5)

Answer 1

tienda sus códigos postales como CHAR (5) en lugar de un tipo numérico, o que su almohadilla de aplicación con ceros cuando lo cargas desde la base de datos. Una manera de hacerlo con PHP usando sprintf():

echo sprintf("%05d", 205); // prints 00205 
echo sprintf("%05d", 1492); // prints 01492 

o podría tener MySQL almohadilla para usted con LPAD():

SELECT LPAD(zip, 5, '0') as zipcode FROM table; 

Aquí está una manera de actualizar y almohadilla todas las filas:

ALTER TABLE `table` CHANGE `zip` `zip` CHAR(5); #changes type 
UPDATE table SET `zip`=LPAD(`zip`, 5, '0'); #pads everything 

Answer 2

Bien, entonces ha cambiado la columna de Número a VARCHAR (5). Ahora necesita actualizar el campo del código postal para que sea acotado por la izquierda. El SQL para hacerlo sería:

UPDATE MyTable 
SET ZipCode = LPAD(ZipCode, 5, '0'); 

Este PAD todos los valores en la columna del código postal de 5 caracteres, añadiendo '0 de la izquierda.

Por supuesto, ahora que tiene todos sus datos antiguos corregidos, debe asegurarse de que sus datos nuevos también sean nulos. Existen varias escuelas de pensamiento sobre la forma correcta de hacerlo:

• Trátelo en la lógica comercial de la aplicación. Ventajas: una solución independiente de la base de datos, no implica aprender más sobre la base de datos. Desventajas: debe manejarse en cualquier lugar que escriba en la base de datos, en todas las aplicaciones.

• Trátelo con un procedimiento almacenado. Ventajas: los procedimientos almacenados imponen reglas comerciales para todos los clientes. Desventajas: los procedimientos almacenados son más complicados que las simples instrucciones INSERT/UPDATE, y no son portátiles en las bases de datos. Un INSERT/UPDATE desnudo puede seguir insertando datos no rellenos de cero.

• Manéjalo con un gatillo.Ventajas: Funcionará para los procedimientos almacenados y las instrucciones INSERT/UPDATE. Desventajas: solución menos portátil. La solución más lenta. Los desencadenantes pueden ser difíciles de corregir.

En este caso, lo manejaría a nivel de aplicación (si es que lo hace) y no a nivel de base de datos. Después de todo, no todos los países usan un código postal de 5 dígitos (ni siquiera en los Estados Unidos; nuestros códigos postales son en realidad Zip + 4 + 2: nnnnn-nnnn-nn) y algunos permiten tanto letras como dígitos. Es mejor NO intentar forzar un formato de datos y aceptar el error de datos ocasionales, que evitar que alguien ingrese el valor correcto, aunque su formato no sea el esperado.

Answer 3

Debe decidir la longitud del código postal (que creo que debería tener 5 caracteres). Luego necesita decirle a MySQL que complete los números.

Supongamos que su tabla se llama mytable y el campo en cuestión es zipcode, tipo smallint. Es necesario emitir la siguiente consulta:

ALTER TABLE mytable CHANGE `zipcode` `zipcode` 
    MEDIUMINT(5) UNSIGNED ZEROFILL NOT NULL; 

La ventaja de este método es que deja sus datos intactos, no hay necesidad de utilizar disparadores durante la inserción de datos/actualizaciones, no hay necesidad de utilizar funciones cuando SELECT las datos y que siempre puede eliminar los ceros adicionales o aumentar la longitud del campo si cambia de opinión.

Answer 4

Todavía tendría sentido crear su campo de código postal como un campo entero sin signo zerofilled.

CREATE TABLE xxx ( zipcode INT(5) ZEROFILL UNSIGNED, ... )

De esa manera MySQL se encarga del acolchado para usted.

Answer 5

CHAR(5) 

o

MEDIUMINT (5) UNSIGNED ZEROFILL 

La primera toma 5 bytes por código postal.

El segundo toma solo 3 bytes por código postal. La opción ZEROFILL es necesaria para los códigos postales con ceros a la izquierda.

Answer 6

LPAD funciona con VARCHAR2 ya que no pone espacios para los bytes sobrantes. DEPA cambia bytes sobrantes/null a ceros en LHS SO tipo de datos debe ser VARCHAR2

Answer 7

se debe utilizar UNSIGNED ZEROFILL en su estructura de la tabla.