Re: Un nuevo impulso al proyecto Ayuda
On Tue, 11 Sep 2001 jamarcer@inicia.es wrote:
> > Falta decidir como se van a generar esos idenficadores para claves
> > únicasde documentos. Manualmente o automáticamente
>
> El cómo generar las claves BD (las llamaré así para diferenciarlas de
> las claves del documento) es un problema menor (en estos momentos
Estoy de acuerdo pero si en determinados directorios los ficheros
con determinada extensión son documentos a tratar, se podría intentar
automatizar parte del trabajo.
> 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.
> > tablas necesarias e inicializarlas con los valores adecuados. El
> > usuarioque no desee usar la BD no tiene porque enterarse de la
> > existencia de un
> > gestor de BD.
>
> ¿La inclusión de un gestor de Base de Datos no penalizará demasiado a
> la aplicación? Me explico:
> * Un usuario puede "asustarse" ante la posibilidad de tener un gestor
> de BD (supongo que hablamos de gestores como MySQL,...) activo. [Si la
> aplicación va como paquete .deb el paquete del gestor estará marcado
> como requerido.
Exacto
> ¿Cómo lo instalo? ¿Estará en la distribución? ¿Cuál escojo?]
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.
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 resulte
amistoso 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.
Mi preocupación es que si hacemos una ayuda muy chula puede que resulte
inutil para los que más la necesitan.
> * Pude que el sistema donde se instale la aplicación no tenga
> demasiados recursos, o se quieran optimizar.
La documentación en si misma ocupará mucho. No tiene sentido montar
el sistema de ayuda sin abundante documentación. Un gestor de BD no
consume recursos de CPU más que cuando le damos caña.
Tener instalada y arrancada una BD no implica que se tenga que notar
en nada. Hará falta algo de espacio pero nada más.
> * Puede que el administrador del sistema no permita tener
> aplicaciones "devoradoras" de recursos (y un gestor BD lo es).
No. No lo es. Si tienes una BD y te dedicas a hacer consultas brutales
a la BD entonces si. Es cuestión de optimizar las consultas en la fase
de programación de las mismas.
Apesar de ello puede que el administrador del sistema no permita
instalar Postgres pero en ese caso que ayude algo al que lo necesite.
> La idea de un gestor de BD me parece muy atractiva, que conste. Pero
> haciendo de abogado del diablo ... me emociono! };-) .
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.
> > create table documento (
> > iddoc char(17) NOT NULL,
> > version varchar(10) NOT NULL,
> > tipodoc char(10) NOT NULL, --
> > (FAQ,HOWTO,MAN,BOOK,ARTICLE,INFO,RFC,TUTORIAL,...
> > mombredoc varchar(50) NOT NULL,
> > fechamodif date, -- fecha ultima modificación
> > frase_docum varchar(400), -- Frase única del documento
> > UNIQUE(mombre, version),
> > PRIMARY KEY(iddoc, version));
>
> Antonio, ¿me puedes decir cómo generas estas definiciones de tablas?
> ¿Es alguna herramienta? Estoy buscando una herramienta de diseño de BD
> en Linux y no la he encontrado (todavía ,-) <<MALDAD: si no la
> encuentro propondré un nuevo proyecto };-0 >>).
Yo uso el editor.
> > create table doclocation (
> > iddoc char(17) NOT NULL,
> > version varchar(10) NOT NULL,
> > formato varchar(10) NOT NULL,
> > url varchar(200) NOT NULL,
> > fechalta date,
> > PRIMARY KEY(iddoc, version, formato, url));
>
> ¿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.
> > Pero las palabras clave hay que detereminar como se guardarán.
> > Podría convenir ponerlas todas juntas dentro de un atributo de
> > 'palabrasclave' en la tabla 'documento'. También se podrían poner
> > en una tabla independiente.
> >
> > create table clavesdoc (
> > iddoc char(17) NOT NULL,
> > version varchar(10) NOT NULL,
> > peso int4,
> > palabraclave varchar(30),
> > PRIMARY KEY(iddoc, version));
>
> ¿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.
> 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.
> 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.
> 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.
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.
> 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.
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.
Si quereis podemos discutir cuales son los temas que necesitan esa labor
de investigación.
Un saludo
Antonio Castro
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/\ /\ Ciberdroide Informática (Tienda de Linux)
\\W// <<< http://www.ciberdroide.com >>>
_|0 0|_
+-oOOO--(___o___)--OOOo----------------------------------------------------+
| . . . . U U . . . . Antonio Castro Snurmacher acastro@ciberdroide.com |
| . . . . . . . . . . |
+()()()----------()()()----------------------------------------------------+
| *** 1.700 sitios clasificados por temas sobre Linux en ***Donde_Linux*** |
| <<< http://www.ciberdroide.com/misc/donde/dondelinux.html >>> |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Reply to: