Re: Que es mejor NULL o CERO

From: Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Jose Vasquez <cibercol(at)gmail(dot)com>, motum hesa <motums(at)gmail(dot)com>, pgsql-es-ayuda(at)postgresql(dot)org
Subject: Re: Que es mejor NULL o CERO
Date: 2009-06-26 05:04:00
Message-ID: 3073cc9b0906252204r6087a28ap4341a776107df3b4@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-es-ayuda

2009/6/25 Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>:
>
> Es fácil:
>
> 1. nunca uses CHAR

hace poco descubrí que existe una razón valida para usar char.

<tale teller mode on>
hace algun tiempo atras, herede un sistema hecho en Visual Fox Pro y
que funcionaba con base de datos M$ SQL server. He estado migrandolo a
postgres (ya llevo varios meses en esto, peor que proyecto
universitario).

He encontrado varios problemas. por ejemplo que si desde vfp envio a
ejecutar "select 1" a postgres llega "select 1::float8" (imaginense el
problema con las funciones que esperan integer), de hecho parece que
todo numero lo pasa a float8.

pero un problema contínuo que he tenido, es que al consultar en el
sistema las facturas a veces (y solo a veces) no me aparecian las
descripciones de los items.
en esa tabla en particular el codigo del item estaba definido como char(18)
por algun motivo cuando el sistema arma consultas usando este valor
(tomado del campo de la forma) el valor sale rellenando espacios en
blanco algo asi: 'PAR00027 ' que al pasarlo a una consulta
sin casteo explicito pasa como text. pero al consultar contra el
maestro de items (ahi el codigo es varchar(50)) los espacios en blanco
no siempre son iguales, si no me estan entendiendo he aqui un ejemplo
practico:

esto en SQL SERVER devuelve 1 o sea que ambas cadenas las considera iguales:
select top 1 case cast('3 ' as varchar(50)) when cast('3' as
varchar) then 1 else 0 end from fcclient

esto en POSTGRES devuelve 0 o sea que las cadenas son diferentes:
select case cast('3 ' as varchar(50)) when cast('3' as text) then 1
else 0 end

la solucion fue cambiar en todas las tablas el codigo del item a
char(50) en ese caso la consulta se convierte en:
select case cast('3 ' as char(50)) when cast('3' as text) then 1 else 0 end
y ahi si devuelve 1

"explicacion" para sql server, varchar y char se comportan igual :S

postgres: select length(cast('3 ' as char(50))), length(cast('3 '
as varchar(50)))
resultado: 1, 4

sql server: select top 1 len(cast('3 ' as varchar(50))), len(cast('3
' as char(50))) from fcclient
resultado: 1, 1

asi que una razon valida para usar char es para migrar aplicaciones
escritas para funcionar con sql server.
</tale teller mode off>

PS:
si se preguntan porque use case para el ejemplo en lugar de algo como:
select top 1 '3 ' = '3' from fcclient
es porque eso en sql server seria algo como
select '3 ' as '3';
es decir, crea una columna llamada '3 ' con valor '3' :(

--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157

In response to

Browse pgsql-es-ayuda by date

  From Date Subject
Next Message Gustavo - Comercio electrónico 3 2009-06-26 08:53:26 necesitamosl la versión 8.1.9 de postgresql, pero no está en el respositorio
Previous Message José Fermín Francisco Ferreras 2009-06-26 02:40:50 RE: seguridad y usuario q hace backup