Skip site navigation (1) Skip section navigation (2)

Re: chars => int

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 (view raw or flat)
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

In response to

Responses

pgsql-es-ayuda by date

Next:From: Edwin QuijadaDate: 2007-01-31 19:53:10
Subject: Re: chars => int
Previous:From: Ricardo Martin GomezDate: 2007-01-31 18:04:32
Subject: Re: chars => int

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group