Re: chars => int

L pregunta seria:
Y hay algo mas para cambiar despues de Postgres????
:(

*-------------------------------------------------------*
*-Edwin Quijada
*-Developer DataBase
*-JQ Microsistemas
*-809-747-2787
* " Si deseas lograr cosas excepcionales debes de hacer cosas fuera de lo
comun"
*-------------------------------------------------------*

>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: [pgsql-es-ayuda] chars => int
>Date: Wed, 31 Jan 2007 16:11:16 -0300
>
>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
>
>---------------------------(fin del mensaje)---------------------------
>TIP 8: explain analyze es tu amigo

_________________________________________________________________
De todo para la Mujer Latina http://latino.msn.com/mujer/