Re:

--- Alvaro Herrera <alvherre(at)commandprompt(dot)com>
escribió:

> HERMES ZAMBRA escribió:
>
> > Aca va un ejemplo no real que hice para vos
> >
> > CREATE TABLE familia (
> > "id_familia" SERIAL,
> > "familia" VARCHAR(100),
> > "coe_fam" DOUBLE PRECISION,
> > CONSTRAINT "idfamilias" PRIMARY
> KEY("id_familia")
> > ) WITHOUT OIDS;
> >
> [...]
>
> > CREATE UNIQUE INDEX "familia_desc_idx" ON familia
> > USING btree ("familia");
>
> Hay una manera mas facil (y un poco mas correcta) de
> hacer esto, y es
> que declares que el campo es UNIQUE directamente.
> Ademas, el PRIMARY
> KEY lo puedes declarar directamente en la columna
> afectada, no tienes
> para que agregarlo en una linea aparte. Quedaria
> asi:
>
> create table familia (
> id_familia serial primary key,
> familia varchar(100) unique,
> coe_fam double precision
> );
>
> Casi siempre es deseable ademas declarar que los
> campos no son nulables,
> es decir, que sus valores no pueden ser NULL:
>
> create table familia (
> id_familia serial primary key,
> familia varchar(100) unique NOT NULL,
> coe_fam double precision NOT NULL
> );
>
> (Las columnas que son parte de una llave primaria
> siempre son no
> nulables, asi que no es necesario declararlo
> separadamente).
>
> --
> Alvaro Herrera
> http://www.CommandPrompt.com/
> PostgreSQL Replication, Consulting, Custom
> Development, 24x7 support
>

Alvaro, de acuerdo en un 98% en todo tu comentario, te
aclaro que el 2 porciento restante es mas alguna duda
que una afirmacion.

El tema de la complicacion es que no lo tome del
manual, si no de la forma en que lo define EMS,
en PGADMIN III, todavia se complica un poco, por que
como muestra el ejemplo, define e default en vez
de usar SERIAL.

CREATE TABLE familia
(
id_familia integer NOT NULL DEFAULT
nextval(('idfamilia'::text)::regclass),
familia character varying(100),
coe_fam double precision,
CONSTRAINT idfamilias PRIMARY KEY (id_familia)
)
WITHOUT OIDS;
ALTER TABLE familia OWNER TO postgres;

-- Index: familia_desc_idx

-- DROP INDEX familia_desc_idx;

CREATE UNIQUE INDEX familia_desc_idx
ON familia
USING btree
(familia);

igualemnte al crearlo en un GUI la complicacion de
hacerlo asi se miniminiza, pero seguro que no es la
forma mas correcta para explicarlo e implementarlo sin
un GUI.

Pensando que en el pg_dump se corrige esto y lo haria
en la forma que tu y el manual lo proponen antes de
preguntarte me tome el trabajito y genere un pg_dump
desde linea de comandos y para esta tabla obtuve esto,
ojo no redefini lo de not null lo cual creo de acuerdo
contigo que es casi siempre correcto.

[
CREATE TABLE familia (
id_familia integer DEFAULT
nextval(('central.idfamilia'::text)::regclass) NOT
NULL,
familia character varying(100),
coe_fam double precision
);

ALTER TABLE familia OWNER TO postgres;

--
-- Name: idfamilia; Type: SEQUENCE; Schema: public;
Owner: postgres
--

CREATE SEQUENCE idfamilia
INCREMENT BY 1
NO MAXVALUE
NO MINVALUE
CACHE 1;

ALTER TABLE central.idfamilia OWNER TO postgres;

--
-- Name: idfamilia; Type: SEQUENCE SET; Schema:
public; Owner: postgres
--

SELECT pg_catalog.setval('idfamilia', 1, true);

ALTER TABLE ONLY familia
ADD CONSTRAINT idfamilias PRIMARY KEY
(id_familia);

CREATE UNIQUE INDEX familia_desc_idx ON familia USING
btree (familia); ]

Duda 1

bueno pg_dump no se esta complicando un poco mas, cual
es la razon ?

Duda 2

Lo de unique en el campo, genera un indice para
aprovechar en las busquedas en que el orden sea el
campo de la descripcion ? o en ese caso de querer
tenerlo vale la pena hacerlo asi separadamente

CREATE UNIQUE INDEX "familia_desc_idx" ON familia
USING btree ("familia");

o teniendo datos es mejor el alter table ?

Disculpa el largo del post, pero es que me parece
bueno primero identificar en que ambiente se generan
los casos, el primero en EMS, el segundo en la
definicion de pg_dump.

Por eso lo del 98%, igualmente creo muy valido tu
planteo por que desde psql, seguro yo tambien tomo tu
camino y no solo en PostgreSQL, en otro sql que
abandone tambien lo hacia como vos propones en osql o
en sqlcmd con igual criterio y tambien el resultado en
los script de backup daban similares al del pg_dump.

Hermes Zambra.

__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
Regístrate ya - http://correo.espanol.yahoo.com/