From: | José Manuel Ruiz <josemanuelruizbaena(at)gmail(dot)com> |
---|---|
To: | Juan Martínez <jeugenio(at)umcervantes(dot)cl> |
Cc: | pgsql-es-ayuda(at)postgresql(dot)org |
Subject: | Re: chars => int |
Date: | 2007-02-01 08:41:10 |
Message-ID: | 83db7ab90702010041k216a3b4cse1cf6cbdc22e23d@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-es-ayuda |
El problema es que tengo instancias de mi aplicación (unas 60) funcionando
en distintos servidores y por eso tengo que mantener compatibilidades y
hacer el sistema lo más portable posible.
No es cuestión de elegir una BD y trabajar sobre ella, cada servidor trabaja
con un motor de BD distinto. Y me apli tiene que funcionar en ellos
independientemente del servidor que me ofrezcan.
Realmente creo que con las fechas debería que optimizarse un poco el
rendimiento, pero no soy quien toda todas las decisiones en esta aplicación.
Más bien soy de los "últimos gatos", así que no seré yo quien decida
optimizar todo el rendimiento de la apli.
Gracias por los consejos.
El día 31/01/07, Juan Martínez <jeugenio(at)umcervantes(dot)cl> escribió:
>
> José Manuel Ruiz escribió:
> > Sé que puede sonar muy raro, pero tengo en mis definición de datos casi
> > todas las tablas como string porque es el tipo de datos más portable a
> > cualquier base de datos.
>
> Por intentar tener una ultra compatibilidad, estas pasando a llevar la
> teoria, lo cual redunda en un rendimiento malo para la BD. Esto no tan
> solo en postgres.
>
> > Sé que así uso muy poco la optimización del motor de base de datos para
> > recorrer campos de otros tipos,
>
> Lo cual no es para nada menor.
>
> > pero me aseguro que puedo portar la base
> > de datos a cualquier otro sitio.
>
> A que te refieres con eso?
>
> > No en todos los motores existe el tipo "timestamp"
>
> Hasta donde se, si existe date. Si no me equivoco, esta definido en SQL92.
>
> > Si uso un tipo fecha, no todas las fechas se almacenan igual, así que
> > tendría que controlar desde mi programa a qué base de datos estoy
> > accediendo y tener en cuenta como trata esa base de datos el tipo fecha.
>
> A ver. Ciertamente la forma en como se almacena una fecha puede ser
> distinto. En postgres, a partir de un determinado datestyle, puedes
> hacer consultas como estas:
>
> SELECT id,nombre FROM foo WHERE fecha > '1/1/2004'::date;
>
> Pero, en la BD la fecha se guarda con otro formato, normalmente
> 'AAAA-MM-DD'.
>
> > Utilizando string sé que los 4 primeros dig son el año, los 2 sig el
> > mes... así es mucho más fácil controlar los datos.
>
> Y si quieres sumarle una determinada cantidad de dias a una fecha?
>
> > Aunque sí, sé que no estoy optimizando el rendimiento de la base de
> datos.
>
> Insisto, lo cual no es para nada menor. Es como dice el refran
> "desvistes un santo para vestir a otro".
>
> > Pero estoy trabajando con una apli de 80 mb de código fuente y se ha
> > estado trabajando así desde el principio. Será complicado cambiarlo
> todo.
>
> Wow...Hace unos mensajes atras lei que era codigo PHP. Esos 80MB es
> mucho codigo. De seguro hay cosas que son trabajables via funciones
> recursivas o con funciones de multiples argumentos. Ciertamente no debe
> ser POO.
>
> La migracion de una base de datos a otra, no es algo de todos los dias.
> Como mucho se hará cada 2 o 3 años. Sacrificar el rendimiento por todo
> ese tiempo, para poder cambiarse de motor de la noche a la mañana a
> otro, no es para nada inteligente.
>
> --
> Juan Martinez G. Mac Iver # 370
> Departamento de Informatica 4997900 - 4997950
> Universidad Miguel de Cervantes Santiago - Chile
> http://download.bblug.usla.org.ar/netiquette.png
>
--
"Comparte lo que sabes, aprende lo que no sepas"
Todo por el conocimiento libre
From | Date | Subject | |
---|---|---|---|
Next Message | José Manuel Ruiz | 2007-02-01 08:49:24 | Re: chars => int |
Previous Message | Jaime Casanova | 2007-02-01 05:31:13 | Re: Compilacion en AIX |