Ayuda con indices en base de datos

[Skeletron]

Novu.. CITO lo mio: (se que odias hacerlo tu)

Tendré que poner INDICE a MES? a DIA? o a Ambos?
Porque leí que exederse de Indices, tambien es malo.. seguramente ustedes saben que convendria..

[^Tifa^]

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

[Skeletron]

Gracias po la respuestaaaaaaaa!!!!!!!!!!!!!!
Y ya que estamos.. Pasate por aqui, a ver si me das una mano:
http://foro.elhacker.net/programacion_general/ayudaextrano_comportamiento_de_sqlite-t271884.0.html

[^Tifa^]

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 :

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).

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).

[-Ramc-]

Preguntaste otra vez lo mismo 

Bueno ya te había respuesto acá

http://foro.elhacker.net/programacion_general/eliminar_post-t271946.0.html

Yo te recomendaría que uses algo como id de la entrada o el nombre de la entrada, ya que si tienes 50 entradas por cada día tendrías que usar como llave primaria la fecha exácta, es decir con hora y segundos de ser posible, pero, igualemente es mejor un indice, no se como usas mes como llave primaria ya que no identifica para nada tu tabla, ni es única para cada campo, dejanos ver como es la estructura de la tabla y que campos tienes ademas de esos.

Creo que es algo parecido, pero, bueno, ya lo resolviste.

Saludos.

[sempus]

raro, yo nunca le pondria un indice a "estos" campos, yo hubiera creado un campo fecha y no uno mes - dia, y crearle el indice a fecha que es mas completo  y estoy casi seguro que el tiempo de respuesta seria mejor si hablamos de una cantidad mayor de datos.

^TiFa^ no conocia la utilidad Explain me parece simplemente magnifica ^^


salu2

[^Tifa^]

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        

[Skeletron]

Tifa.. tengo los 18.500 entradas en un .txt.. son lineas de texto.. aun no las he pasado a la base de datos original..
Digamos que no es ningun tipo de problema modificar las columas de la base de datos, porque aun no la he creado.. y las entradas en -txt son solamente los valores del campo: "Texto" porque el campo DIA y MES los voy creando automaticamente.. (dando valores respecto el nombre del archivo..)

Así que.. como me recomendas hacer la tabla?
una columna FECHA? y la columna TEXTO?
FECHA deberia ser un VARCHAR?
Porque cuando le pongo formato DATE, y hago un select y me devuelve tambien la HORA.. (supongamos que inserte: 21-01-1990, me devuelve 21-01-1990 00:00:00)
Y no quiero que sea así... tambien estoy renegando mucho con el formato DATE pqroue no encuentro ejemplos o documentacion en español de como utilizarlo.. hay poco en la red de SQLite (y he buscado mucho... lo juro..)

Dime que harias tu..

[^Tifa^]

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).

[^Tifa^]

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.