Re: recomendacion para BD grande

2008/5/26 Gabriel Ferro <gabrielrferro(at)yahoo(dot)com(dot)ar>:
> Aclarando que las tablas que les pase no estan completas ya que no estan
> algunos campos extras que estoy obligado a usar porque en realidad estoy
> pasando archivos XLS y DBF con distintas estructuras,tratando de unificar
> todos los padrones y otros datos que tenemos por todos lados
> Vamos por partes:
> -En efecto Nombre tiene los apellidos y los nombres, no me sirven de clave
> porque Martinez Pedro hay miles.
> -Lo de BD operativo no te entiendo, si te refieres a que si se usara o solo
> es experimental, si, la usaremos.
> -autoincrementable como clave: pienso que es mejor buscar usando las claves
> primarias y como las busquedas son por nombres o por documento (doc+tipodoc)
> use lo ultimo como clave ya que es irrepetible.
> - las otras tablas tienen clave al resumirlas no las puse, se las paso
> completas
>
> PERSONAS
> documento character varying(10) NOT NULL,
> tipodoc smallint NOT NULL DEFAULT 13
> nombre character varying(200) NOT NULL,
> sexo character(1),
> datos character varying(255),
> fechanac timestamp without time zone,
> CONSTRAINT personas_pkey PRIMARY KEY (documento, tipodoc),
> CONSTRAINT personas_tipodoc_fkey FOREIGN KEY (tipodoc)
> REFERENCES analisis.docu (clave) MATCH SIMPLE
> ON UPDATE NO ACTION ON DELETE NO ACTION
>
> LOCALIDADES
> codprov integer NOT NULL,
> coddpto integer NOT NULL,
> localidad character varying(200) NOT NULL,
> claveloc serial NOT NULL,
> CONSTRAINT localidades_pkey PRIMARY KEY (claveloc)
>
> DEPARTAMENTOS
> coddpto integer NOT NULL,
> departamento character varying(50),
> codprov integer NOT NULL,
> CONSTRAINT departamentos_pkey PRIMARY KEY (codprov, coddpto),
> CONSTRAINT departamentos_codprov_fkey FOREIGN KEY (codprov)
> REFERENCES analisis.provincias (codprov) MATCH SIMPLE
> ON UPDATE NO ACTION ON DELETE NO ACTION
>
> PROVINCIAS
> codprov smallint NOT NULL,
> provincia character varying(50),
> CONSTRAINT provincias_pkey PRIMARY KEY (codprov)
>
> PERSONALOC
> documento character varying(10) NOT NULL,
> tipodoc smallint NOT NULL,
> claveloc integer NOT NULL
> CONSTRAINT personaloc_pkey PRIMARY KEY (tipodoc, documento,
> claveloc),
> CONSTRAINT personaloc_claveloc_fkey FOREIGN KEY (claveloc)
> REFERENCES analisis.localidades (claveloc) MATCH SIMPLE
> ON UPDATE NO ACTION ON DELETE NO ACTION
>
> Saludos
>
> ________________________________
> Yahoo! Encuentros
> Ahora encontrar pareja es mucho más fácil, probá el nuevo Yahoo! Encuentros.
> Visitá http://yahoo.cupidovirtual.com/servlet/NewRegistration

-En efecto Nombre tiene los apellidos y los nombres, no me sirven de clave
porque Martinez Pedro hay miles. --> En ningun caso mi propuesta
siquiera fue por ese lado (seria bastante poco amistoso de mi parte
tentar de darte una solucion de ese tipo)... solo era la duda porque
generalmente se sepraran para agilizar las busquedas ...

-autoincrementable como clave: pienso que es mejor buscar usando las
claves primarias y como las busquedas son por nombres o por documento
(doc+tipodoc) use lo ultimo como clave ya que es irrepetible. -->
Como ? buscaras solo por clave??? entiendo que las busqueda sobre esa
tabla seran por cualquier campo o sea nombre, sexo, edad etc... una
cosa son las busquedas y otra son los insert de datos, tal como te
comente al parecer PG tiene bastante optimizado el tema de calculo de
autoincrementables por lo que pasa a ser una buena tecnica para
administrar los tiempo de ingreso de datos...

- Respecto a si es una BD operativa me referia a que no estas
haciendo un DataWareHouse o DataMart era solo por eso...
Solo eso puedo aportarte por el momento yo me iria por el lado de
claves autoincrementables despues las busquedas las puedes optimizar
analizando colocando indices donde corresponda, etc etc...
Ahh y trata de separar tu campo nombre en el futuro puede evitarte
dolores de cabeza...
Slds.

--
----------------------
Slds.
jchavez
linux User #397972 on http://counter.li.org/