Re: Un nuevo impulso al proyecto Ayuda

[<jamarcer@inicia.es>]

----- Mensaje original -----
De: Antonio Castro <acastro@ciberdroide.com>
Fecha: Martes, Septiembre 11, 2001 1:27 pm
Asunto: Re: Un nuevo impulso al proyecto Ayuda

> ...
> > Ya sé que la aplicación va a tener un ambito de operación local, 
> pero 
> > la generación de la base de datos va a ser un proceso 
> distribuido (cada 
> > documentalista estará "aislado" en sus PC`s/Cuentas tratando sus 
> > documentos) con un repositorio final común.
> 
> La información de la situación del documento va en una tabla aparte.

No me refiero a la tabla. Me refiero al origen de la información para 
esa/s tabla/s. Un documentalista va a decidir que documento/s tratar, 
los va a coger de algún sitio, y los va a catalogar. ¿Cómo va a incluir 
sus conclusiones en la tabla? Creo que será necesario un interfaz entre 
el documentalista y la tabla para insertar los datos. Y si no tenemos 
clara la BD, sería buena idea definir un sistema de almacenamiento 
temporal (una formulario en papel me sirve) para que el documentalista 
archive su trabajo. Luego sería "simplemente" cargar la tabla (o lo que 
se decida hacer).

> ...
> Yo esataba pensado en Postgresql. Se puede montar algo más general
> usando ODBC y que pueda usar distintos gestores de BD pero eso supone
> que el usuario deberá elegir cual BD instalar y todo sería algo más
> complicado.
> 

Estoy contigo. No conozco lo suficiente la configuración de un gestor 
de BD (MySQL o Postgresql u otro), pero mi Debian Potato me ha 
instalado y configurado sin problemas Postgresql. Podemos centrarnos en 
un desarrollo con este gestor y más adelante buscar la forma de 
globalizar (detectar si está instalado o no un gestor, identificarlo y 
configurar la aplicación para usarlo. Pero eso es para nota, ¿no? ;-) ).

> Este es un punto muy delicado porque limitar la libertad de 
> elección 
> es algo muy mal visto. Sin embargo si el proyecto ayuda se enreda con
> tecnologías potentes y flexibles resultará mucho más dificil que 
> resulteamistoso y facil de usar para todo el mundo. Creo que el 
> proyecto ayuda
> debe resultar lo más simple de usar que se pueda. Muchas veces el
> problema es que lo que apetece hacer no es lo que se necesita hacer.
>
> Lo que quiero decir es que siempre apetece hacer cosas chulas.
> El resultado final sería mucho más chulo si funcionara en XWindows y
> en un entorno de red permitiendo además la elección de una amplia 
> variedad de gestores de BD. 
> 

Si lo dejamos "abierto" no creo que sea gran problema portarlo a otros 
gestores de BDs.
No creo que práctico y chulo sean incompatibles
 
> ...
> La alternativa podría ser por ejemplo usar perl o awk sobre 
> ficheros de 
> texto pero eso seguramente consumiría más recursos. Tambien podría 
> resultar más dificil de programar.
>

Puede ser una linea de investigación. Pero opino como tú, definamos un 
entorno inicial y desarrollemos para ello.
 
>...
> > ¿Porqué el formato es clave? Creo que el formato es una 
> característica 
> > del enlace, y no al revés.
> 
> Eso indica que hay una sola clave formada por iddoc, version, 
> formato, url.
> No puede haber dos registros con la misma combinacion de valores para
> esos cuatro campos.
> 

De acuerdo. Pero que <formato> sea parte de la clave primaria no me 
parece necesario. Si el campo no existiese seguiría teniendo la 
localización del documento. Y <formato> me identifica el formato del 
documento apuntado por <url>

> ... 
> > ¿El documento sólo puede tener una clave?
> 
> PRIMARY KEY es clave principal y solo puede haber una.
> se pueden crear otros indices para agilizar accesos por otros
> campos. Usar muchos indices no es bueno porque penaliza las altas
> y las modificaciones.
> 

¡Que jaleo! Entre clave de documento, clave de tabla, clave primaria de 
la tabla,... ya no sabemos de lo que hablamos (Por cierto: no nos hemos 
pasado con tantos tecnicismos ) Se te ha debido pasar porque con la 
clave primaria así definida sólo puedes tener un registro por <iddoc> y 
<version>

> > Relacciones entre tablas:
> > DOCUMENTO - CARACTERÍSTICAS  1 a 1   Las características de un 
> documento>                                      son únicas.
> > DOCUMENTO - ABSTRACT         1 a 1   El abstract de un documento 
> es 
> 
> Dado que CARACTERISTICAS y ABSTRACT son relaciones 1 a 1 con DOCUMENTO
> y que no tienen relacion con ninguna otra tabla se deben considerar
> atributos de DOCUMENTO. 
>

Ok. A nivel físico pueden estar en la misma tabla. Pero funcionalmente 
queda más claro plantearlo así (y los demás pueden entendernos mejor)
 
> > DOCUMENTO - LOCALIZACIÓN     1 a n   El documento tiene al menos una
> >                                      localización.
> > DOCUMENTO - CLAVES DOCUMENTO 1 a n   El documento tiene al menos 
> una 
> >                                      clave que le cataloga.
> Esta  sería una relacion n a n.

No estoy de acuerdo. La relación n a n se establece entre DOCUMENTOS y 
CLAVES. CLAVE DOCUMENTOS es una de esas tablas que aparecen en algunos 
prodedimientos de diseño para romper las relaciones n a n. Un documento 
puede tener una o varias claves, y una clave puede pertenecer al 
conjunto de claves de ninguno(puede darse el caso), uno o más 
documentos.

> 
> > CLAVES - CLAVES DOCUMENTO    1 a 0,n Una clave puede no 
> catalogar, o 
> >                                      catalogar a un documento, o 
> a más
> >                                      de uno.  
> > CLAVES - DESCRIPCIÓN CLAVE   1 a 1   Cada clave tiene su 
> descripción.> 
> > La idea principal es separar los "indices de búsqueda" en tablas 
> más 
> > ágiles (sin grandes descripciones,... ). 
> 
> Las tablas no son más agiles por tener menos atributos o por tener
> atributos más pequeños. 
> 
> CLAVES DOCUMENTO, CLAVES, y DESCRIPCION CLAVE. En realidad debería
> ser una única tabla CLAVES.
> 

CLAVES y DESCRIPCION CLAVES a nivel físico pueden ser una tabla. De 
acuerdo.

> Yo no me pongo a normalizar las bases de datos porque ya tengo 
> bastante 
> práctica y ya me salen diseños bastante normalizados.
> 
> En tu caso es un tema que desconoces. Hacer una aplicación sobre una
> mal diseño de BD es una pesadilla.
> 

¿Me conoces lo suficiente, Antonio, para afirmar que desconozco el 
tema? Por eso me quejo de lo poco que sabemos los unos de los otros.

Y tienes razón. Un mal diseño de BD puede ser un infierno. 

> > La tabla CLAVE es una tabla autocontenida o autoreferenciada. No 
> es 
> > necesaria la clave-predecesora: se conoce buscando aquella clave 
> que 
> > tiene como clave-sucesora la clave referencia.
> 
> Una clave puede tener varias predecesoras y varias sucesoras pero
> no todos los recorridos son validos. Yo propuse esta forma de limitar
> la libertad de sucesión de una clave en función de su predecesora.
> 

¡Definamos los recorridos! De que nos sirve plantear la BD si no 
sabemos qué queremos.

> En mi opinión no solo faltan dedos dispuestos a aporrear teclas. El
> proyecto no está bien definido y nos falta información. Quizas todos
> deberíamos estudiar un poco más, y buscar modelos de cosas ya echas.
> 
> Propongo que la gente haga un parentesis y trabaje individualmente por
> su cuenta buscando información porque a mi juicio estamos entrando 
> en 
> una dinámica poco productiva.
> 

Yo me conformo con que la gente me diga si se entera, si le parece bien 
nuestras ideas, o que nos cuente las suyas, ...

> Si quereis podemos discutir cuales son los temas que necesitan esa 
> laborde investigación.
> 

¿...?

> 
> Un saludo
> 
> Antonio Castro
 

Un saludo
Jesús Antonio Martínez Cerezal
jamarcer@inicia.es



_______________________________________________________________
Date de alta en inicia y dispondrás de correo y espacio para tu página 
personal. http://inicia.es