Si aun haciendo los pasos requeridos te sigue mostrando la fecha en los campos tipo DATE asi :

2009:11:21 15:00:00

Puedes utilizar SUBSTR para ir llenando ese campo    sino entiendes el funcionamiento de SUBSTR exponlo y se te ayuda. Pero es preferible que tengas el campo con datos DATE en vez de dividido un campo mes, otro año, otro dia.

Yo crease el campo FECHA DATE, de verdad no tengo palabras para la situacion que te ocurre en relacion a declarar un campo tipo DATE y que SQLite insista en insertar datos como si dicho campo fuese FECHA DATETIME.

El estandar de datos primitivos en todas las DB relacionales profesionales que he visto y conozco (Y la implementacion del estandar ANSI SQL por igual afirma) que un tipo de dato DATE debe registrar los datos insertados de esta manera:

'YYYY-MM-DD' (año-Mes-Dia)

Haz una prueba, create una simple tabla en SQLite con 1 campo FECHA DATE y inserta un registro de la siguiente manera:

INSERT INTO TABLA XXXX VALUES('1990-01-21')

Y luego haz un SELECT deberia devolverte el valor sin la hora pegada (Siempre y cuando el campo sea tipo DATE y no DATETIME).

Ohh lo siento, no se que es una MIRTHA 

Lo que queria decirte es, que segun su web en SQLite el tipo de datos que recibe un campo, no lo define el campo en cuestion (Como en otras base de datos), sino que el tipo de datos que recibe un campo lo define en tiempo real el dato que insertes en un campo. Por ende si tu declaras en tu tabla un campo (Fecha DATE) y le insertas como registro 'MARIO' el lo acceptara lol   

Suena un poco cruel, pero me sorprende la poca factibilidad que lleva esta base de datos, primeramente no posee un usuario que controle permisos sobre objetos ni tablas, tampoco requiere contraseña, y encima de esto los campos de una tabla acceptan cualquier tipo de datos porque esos tipos de datos se definen en tiempo real cuando insertes un dato    entonces me pregunto para que posee tipos de datos? si a la larga el campo podra tener de tipo de datos 'Madera' y hara poco caso, la definicion se hara cuando yo empieze a insertar datos en ese campo... si son numericos pues SQLite asumira que ese campo es INTEGER aunque diga que es tipo 'Madera'  y si la segunda insercion en el mismo campo es de caracteres? pasara a manejarlo como VARCHAR??? y que pasa con el registro anterior insertado en el mismo campo entonces SQLite manejara el registro 1 del campo como INTEGER y el registro 2 como VARCHAR??  Correspondiendo ambos registros al mismo campo? No quisiera dar esto por hecho, pero si es asi....no es muy eficiente que se diga. Para proyectos chiquitos considero que estaria super bien usar este motor en vez de Access por ejemplo, pero para un proyecto serio .... no se 

Bueno en realidad cielo, el MAX(Ciudad) lo que hace es mostrarte la Ciudad en este caso donde el caracter de inicio de la palabra se aproxime mas a la 'Z' del alfabeto que es la ultima palabra del alfabeto.

Si tu tienes 2 Ciudades:

Argentina
Mexico

Y haces MAX(Ciudad) el te devolvera la palabra que su primer caracter se aproxime a la 'Z' en este caso 'Mexico' su primer caracter 'M' esta mas cercano a la 'Z' que la 'A' de 'Argentina'    Asi es como va MAX en caracteres.

Mysqldump hace backups logicos no fisicos. Con un script en crontab como te dice el amigo aca podrias hacer el dumpeo de las tablas (Que para mejor atomicidad es preferible bloquear las tablas en modo lectura, o pasarle los parametros correspondientes a mysqldump para que lo haga por ti... en este caso  --opt ) y para mayor rapidez de dumpeo, puedes desabilitar temporalmente las llaves he indices --disable-keys

Mi recomendacion de bloquear tablas ante lectura/escritura es por el mero hecho que utilizar mysqldump sin parametros, hara un backup logico de la estructura de las tablas bloqueando cada campo correspondiente por donde vaya mysqldump, digase, una tabla con los valores:

nombres char  --> (suponte que tienes 5,000 registros)
apellidos char --> (suponte que tienes 5,100 registros)

Ahora usas mysqldump sin parametros:

mysqldump bloquea a modo lectura/escritura (mientras va haciendo el dump) el campo :
nombres char

Sin embargo el campo (apellidos char) donde mysqldump aun no ha llegado (No llegara hasta que no termine de archivar los 5,000 registros del campo nombre) en el campo apellidos aun sigue vigente sin ningun tipo de bloqueos y cualquier usuario si tiene capacidad de realizar cualquier tipo de transaccion (UPDATE, INSERT, DELETE) en el campo apellidos, cuando mysqldump termine de archivar nombres, pasara a apellidos por ende desbloqueara el campo nombres y bloqueare el campo apellidos para realizar el mismo proceso, por lo tanto en lo que va archivando campo apellidos (que esta bloqueado vs escritura) cualquier dato puede ser insertado o actualizado en el campo 'nombres' y NO, estos ultimos datos no seran parte del backup que esta realizando mysqldump, ya mysqldump termino con el campo 'nombres' y no volvera para atras, por ende este tipo de backup puede quedar inconsistente (por falta de datos en tiempo real).

Pero si bloqueas las tablas antes de iniciar el dump, como no es posible escribir en ninguno de los campos de una tabla, todos los datos seran consistentes y actuales    Al menos que quieras hacer el backup de manera fisica con mysqlhotcopy pero eso ya es otra historia.

Me encontre un poco extranio que lleve separado una fecha (1 campo mes, 1 campo dia) existiendo tipo de datos DATE pero... luego dije ya que el chico tiene 18,500 registros jejejejeje.. como que alterar la tabla para modificar esto es un poco complicado y forzado. Entonces, para no complicarle mas el asunto, lo mas facil seria que hiciese un campo ID que le sirva de indice (En este sentido si puede alterar la tabla para agregarle ese campo exclusivo) y llenarlo con un bucle for hecho en cualquier Script que corra desde 1 hasta 18,500 (que son la cantidad de registros que el tiene) pero luego el dio la informacion que por dia podian existir 50 registros... entonces aca ya variaria el asunto del campo ID que podria continuar siendo indice (para usarlo de optimizacion en una consulta) pero dicho campo ID deberia tener un valor unico numerico en los 18,500 registros (El que el quiera hasta el numero 1 si gusta, asi el campo ID que es indice al tener definido el valor '1' es siempre una constante)  y que use tambien de index(mes,dia) asi podria filtrar mejor el asunto a la hora de busquedad sin mucho esfuerzo.

Aunque por lo que veo SQLite descarta muchisimas cosas 'normales' en otras DB profesionales, por ende, desconozco si realmente SQLite haga o no mucho caso a tener campos indices y optimizacion de lectura en el HD.

Por cierto sempus, es bastante utilizada la clausula EXPLAIN en base de datos relacionales, al menos en MySQL y Oracle las suelo utilizar bastante y mejora sobremanera el tiempo de lectura de bytes en disco    te recomiendo a ti, y a quien sea que investigue mas sobre EXPLAIN en base de datos, ya que estoy consciente que muchos 'programadores webs' piensan que saber SQL es saber manipular  a medias (SELECT, INSERT, UPDATE) y despues de un tiempo cuando la DB comienza a crecer y crecer se preguntan porque va tan lenta mi pagina web en relacion a las consultas antes no era asi    (Claro antes hablabamos de a lo mejor 1,000 registros y hoy hablamos de 500,000 mil registros) Y esto sin Tunning es critico.

Un besote enorme        

Te aseguro que al leer este post, pense que SQLite tenia un bug enorme (Ya que eso que hiciste en otra base de datos relacional... jamas te permitiria).

Pero esta semi explicado en su website    Te hago un mini-resumen


http://www.sqlite.org/datatype3.html

Por ende, podrias crear una tabla con campos con tipos de datos 'CASITA' o 'NONE' y no importaria (En SQLite) ya que el definira que tipo de datos lleve ese campo cuando le ingreses el primer registro... en resumen, en esta base de datos aparentemente puedes meter cualquier tipo de datos en cualquier campo    ya que no controla lo que guarda... (A excepcion como dice su website, si tienes definido una llave primaria de tipo INTEGER aqui si que ya no puedes insertar datos caracteres en dicho campo, pero solo ahi aplicaria)

Cruel pero cierto....  

No conozco en abundancia el funcionamiento interno de SQLite, pero hasta lo poco que he visto en su website, tiene ciertas diferencias en cuanto a forma de funcionar en relacion a una base de datos SQL profesional. Por ejemplo, no maneja permisos de acceso de usuarios    por ende puedes obviar el punto cuando afirme :


Ya que esto al menos en SQLite no aplica, no hay usuarios con distintos privilegios sobre objetos o tablas (tragico para la seguridad  ) por ende, a lo mejor (aunque no te lo puedo asegurar) utilizar indices en SQLite sea algo relativo, y esto no implique optimizacion alguna a la hora de una busquedad (Como dice el chiquito Novlucker       ), aunque puede que si habria que indagar mas sobre el funcionamiento interno de esta DB (Ya que varia demasiado de una base de datos relacional profesional).

Gracias Novlucker, aunque para nada quize descartar tu opcion encanto    solo que 18,500 registros es alguito  largo y dije bueno si el chico puede ahorrarse unos bytes de segundos en lectura del disco poseyendo indices, porque no.

Yo conozco casi nada del funcionamiento interno de SQLite que conste, toda esta ejemplificacion es en base a otras bases de datos relacionales mas profesionales (como MySQL, Oracle, SQL Server) y ya que SQLite pretende ir acorde con el ANSI SQL puede que posea las mismas caracteristicas de funcionamiento que un motor de base de datos profesional. Por lo general, un motor de base de datos profesional funciona asi cada vez que haces una consulta por mas minima que sea :

Paso uno : verificar la metada para ver que permisos posee el usuario conectado a la DB en ese momento sobre esa tabla(si posee permisos de lectura, escritura, modificacion, etc).

Paso Dos: En tu caso que no tienes indices, aunque solo requieras 50 registros como no hay indices el recorrera los 18,500 actuales de registros antes de devolverte los 50 registros (Y si en esos registros tienes valores nulos tarda unos bytes mas en su busquedad).

Paso Tres: Ya finalizado devuelve los datos.

No temas sobre cantidad de indices soportados en una DB, por lo general acceptan un maximo de 64 y mas indices....

Si gustas usas indices por optimizacion mas que todo, pero sino te conviene ya sabes. Si te recomiendo que uses de indice entonces DIA y MES

De hecho como soy un poco pesima exponiendome, lo hago mas visual:

Tengo 1 simple tabla con 3 datitos:

 
mysql> SELECT * FROM ejemplo;
+------+------+--------+     
| dia  | mes  | nombre |     
+------+------+--------+     
|    1 |   11 | Maria  |
|    1 |   10 | Juan   |
|    2 |    9 | Pedro  |
+------+------+--------+
3 ROWS IN SET (0.00 sec)
 
 

No tengo indices como tu. Asi que hago una mera consulta sencilla:

 
mysql> SELECT * FROM ejemplo WHERE dia = 1;
+------+------+--------+
| dia  | mes  | nombre |
+------+------+--------+
|    1 |   11 | Maria  |
|    1 |   10 | Juan   |
+------+------+--------+
2 ROWS IN SET (0.00 sec)
 
 
 

Todo bien? visualmente si.... ahora veamos como el motor analiza en verdad el asunto de busquedad en el disco, usemos la herramienta de preferencia EXPLAIN (para tunnings en base de datos)

 
-mysql> EXPLAIN SELECT * FROM ejemplo WHERE dia = 1;
+----+-------------+---------+------+---------------+------+---------+------+------+-------------+
| id | select_type | TABLE   | TYPE | possible_keys | KEY  | key_len | REF  | ROWS | Extra       |
+----+-------------+---------+------+---------------+------+---------+------+------+-------------+
|  1 | SIMPLE      | ejemplo | ALL  | NULL          | NULL | NULL    | NULL |    3 | USING WHERE | 
+----+-------------+---------+------+---------------+------+---------+------+------+-------------+ 
1 ROW IN SET (0.00 sec)                                                                            
 
mysql> EXPLAIN SELECT * FROM ejemplo WHERE dia = 1 AND mes = 11;
+----+-------------+---------+------+---------------+------+---------+------+------+-------------+
| id | select_type | TABLE   | TYPE | possible_keys | KEY  | key_len | REF  | ROWS | Extra       |
+----+-------------+---------+------+---------------+------+---------+------+------+-------------+
|  1 | SIMPLE      | ejemplo | ALL  | NULL          | NULL | NULL    | NULL |    3 | USING WHERE |
+----+-------------+---------+------+---------------+------+---------+------+------+-------------+
1 ROW IN SET (0.00 sec)
 
 
 
 

Fijate la parte donde dice:  rows - 3  (como no tengo indices definidos en mi tabla, aunque haga la busquedad por una constante dia = 1 el motor de la DB debe buscar en todos los registros para dar con la ubicacion de ese registro, en este caso recorrio todos los datos de mi tabla que son apenas 3.... en tu caso serian 18,500 registros a recorrer antes de devolverte donde esta el valor).

Ahora creo un indice en mi tabla:

 
mysql> CREATE INDEX indice ON ejemplo(dia);
Query OK, 3 ROWS affected (0.05 sec)
Records: 3  Duplicates: 0  Warnings: 0
 
mysql> EXPLAIN SELECT * FROM ejemplo WHERE dia = 1;
+----+-------------+---------+------+---------------+--------+---------+-------+------+-------------+
| id | select_type | TABLE   | TYPE | possible_keys | KEY    | key_len | REF   | ROWS | Extra       |
+----+-------------+---------+------+---------------+--------+---------+-------+------+-------------+
|  1 | SIMPLE      | ejemplo | REF  | indice        | indice | 5       | const |    1 | USING WHERE |
+----+-------------+---------+------+---------------+--------+---------+-------+------+-------------+
1 ROW IN SET (0.01 sec)
 
mysql> EXPLAIN SELECT * FROM ejemplo WHERE dia = 3;
+----+-------------+---------+------+---------------+--------+---------+-------+------+-------------+
| id | select_type | TABLE   | TYPE | possible_keys | KEY    | key_len | REF   | ROWS | Extra       |
+----+-------------+---------+------+---------------+--------+---------+-------+------+-------------+
|  1 | SIMPLE      | ejemplo | REF  | indice        | indice | 5       | const |    1 | USING WHERE |
+----+-------------+---------+------+---------------+--------+---------+-------+------+-------------+
1 ROW IN SET (0.01 sec)
 
 

Que curioso ahora fijate en la parte donde dice rows -> 1 (recorrio 1 sola fila para dar exactamente con mi registro en vez de recorrer todos los registros como haria sino tengo un indice definido).