From: | Juan Martínez <jeugenio(at)umcervantes(dot)cl> |
---|---|
To: | lordjose84(at)gmail(dot)com |
Cc: | pgsql-es-ayuda(at)postgresql(dot)org |
Subject: | Re: chars => int |
Date: | 2007-01-31 19:11:16 |
Message-ID: | 45C0E9D4.3080601@umcervantes.cl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-es-ayuda |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Edwin Quijada | 2007-01-31 19:53:10 | Re: chars => int |
Previous Message | Ricardo Martin Gomez | 2007-01-31 18:04:32 | Re: chars => int |