Re: longitud tipo dato serial

From: "Hector R(dot) De los Santos " <zahory(at)gmail(dot)com>
To: Gunnar Wolf <gwolf(at)gwolf(dot)org>
Cc: Gustavo Rosso <grosso(at)sadaic(dot)org(dot)ar>, Victor Avendaño <avenda(at)gmail(dot)com>, pgsql-es-ayuda(at)postgresql(dot)org
Subject: Re: longitud tipo dato serial
Date: 2010-04-13 18:28:45
Message-ID: v2j3efb88e61004131128i771edae6ocf12ea79a90caa9a@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-es-ayuda

:: HDS Consultores TI
Servidores | Redes | Programacion | GNU/Linux | PostgreSQL
Web: http://hdsconsultores.net
Blog: http://codigohds.com
Linux User #:320363

El 13 de abril de 2010 14:12, Gunnar Wolf <gwolf(at)gwolf(dot)org> escribió:

> Gustavo Rosso dijo [Mon, Mar 22, 2010 at 10:53:18AM -0300]:
> >> Parece que me expresé mal, no necesariamente necesito un tipo de
> >> datos, pero sería genial que así se pudiera generar, lo que deseo es
> >> poder tener algo como un character varing de longitud 3 que sea
> >> autoincrementable, osea que se baya generando de la siguiente manera
> >> 001, 002, 003..... 012,013,014, ... etc debido a que necesito grabar
> >> esos 3 caracteres y como serial no me conserva los ceros, quizas otra
> >> solucion seria poder guardar el serial pero con los ceros delante cosa
> >> que yo al traerlos o exportarlos siempre pueda manipular esos 3
> >> caracteres... me explico???
> >
> > Un trigger que llame a una funcion antes del insert?
>
> (Sí, esta es una consulta más bien vieja, pero bueno... Me sorprende
> que nadie haya dicho esto hasta ahora ;-) )
>

Esta fue la primera respuesta que se le dio:

"Eso de poner los rellenar con ceros lo puedes hacer via tu lenguaje o via
SQL con PostgreSQL usando lpad(). Te recomiendo que tengas el campo entero o
serial y hagas el relleno de ceros con lpad(),
Leete esto:
http://www.postgresql.org/docs/8.4/static/functions-string.html "

Creo que no tiene mucha diferencia con lo que le recomiendas....

>
> Gustavo, el meollo de esto es para qué quieres _guardarlo_ en ese
> formato. Un campo serial es por naturaleza entero, esto agiliza su
> manejo interno (ordenamiento, búsqueda, comparación).
>
> Un campo de tipo entero _no tiene_ representación directa. Esto es, en
> la representación física de los datos (en el disco) no aparece el
> valor '1', '2', '3', etcétera — Aparece un campo de 32 bits que tiene
> el valor numérico en cuestión, pero no de una manera que tú lo puedas
> leer. Ilustro, con una conversión bastante simplista. En Ruby:
>
> def disgrega(palabra)
> (0..palabra.size-1).map{|i| palabra[i]}
> end
>
> def suma(arreglo=[])
> return 0 if arreglo.empty?
> return arreglo[-1].to_i + 256*suma(arreglo[0..-2])
> end
>
> La primer función separa una cadena en sus bytes constitutivos:
>
> >> disgrega('hola')
> => [104, 111, 108, 97]
>
> La segunda función los suma, multiplicando cada posición por 256, para
> formar un entero. Esto es,
>
> >> suma(disgrega('hola'))
> => 1752132705
>
> Ahora, ¿qué pasa con la representación que buscas guardar? Veamos:
>
> >> suma(disgrega('001'))
> => 3158065
> >> suma(disgrega('002'))
> => 3158066
> >> suma(disgrega('003'))
> => 3158067
>
> Esto porque, claro está, cada '0' vale 48. Entonces, si bien en la
> práctica podrías lograr tu propósito representando enteros como
> cadenas, sería altamente ineficiente. Las comparaciones funcionarían,
> aunque dejarían huecos – Por ejemplo:
>
> >> suma(disgrega('009'))
> => 3158073
> >> suma(disgrega('010'))
> => 3158320
>
> Acá tienes un brinco de 247 (esto es, 256-9, ¿te queda claro por qué?
> :-) )
>
> Bueno, a lo que iba con todo esto: Te conviene guardar los datos en un
> campo entero. A PostgreSQL le es mucho más agradable trabajar con este
> tipo de datos, y lo hace rápido y de buena gana. Las cadenas siempre
> duelen y lo ponen de mal humor. Y tú no quieres eso.
>
> Obviamente, quieres manejar el consecutivo formateado en tu
> aplicación. Acá, una de dos: O formateas desde Postgres _después_ de
> obtener el valor (SELECT lpad(id::text, 3, '0') FROM tabla WHERE ...),
> o manejas el valor íntegramente como numérico dentro de Postgres y le
> das formato en tu aplicación, al momento de presentarla al usuario
> (p.ej. con un sprintf('%03d', id) o su equivalente en tu lenguaje
> favorito).
>
> Pero bueno, en resumen: Te conviene separar el dato de su
> presentación. No creo que haya ninguna razón _real_ para que busques
> almacenarlo con los ceros precedentes. Sólo al presentarlo al
> usuario.
>
> Saludos,
>
> --
> Gunnar Wolf • gwolf(at)gwolf(dot)org • (+52-55)5623-0154 / 1451-2244
> --
> TIP 2: puedes desuscribirte de todas las listas simultáneamente
> (envía "unregister TuDirecciónDeCorreo" a majordomo(at)postgresql(dot)org)
>

In response to

Responses

Browse pgsql-es-ayuda by date

  From Date Subject
Next Message Gunnar Wolf 2010-04-13 18:53:46 Re: longitud tipo dato serial
Previous Message Gunnar Wolf 2010-04-13 18:12:29 Re: longitud tipo dato serial