Re: Un nuevo impulso al proyecto Ayuda
----- Mensaje original -----
De: Antonio Castro <acastro@ciberdroide.com>
Fecha: Lunes, Septiembre 10, 2001 5:39 pm
Asunto: Re: Un nuevo impulso al proyecto Ayuda
> ...
> No tengo claro la necesidad de que la generación de claves tenga
> que
> ser automática .
>
> ...
>
> 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
;-) ). Lo propuse automático por comodidad para el
documentalista: "sólo" tiene que dedicarse al documento, dejando el
cómo se manipula la información que el genera en "manos" de la
aplicación. Y si por casualidad dos claves BD fuesen iguales, sería la
aplicación la que gestionaría la solución.
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.
> ...
> > Aunque el concepto de local es un poco relativo, supongamos que
> sólo es
> > un usuario. ¿Sabrá nuestro usuario instalar, activar y mantener
> un
> > sistema gestor de BD's?
>
> Interesante pregunta. Ya dige que no era facil ponerse en la piel de
> un novato y acabas de hacer una observación interesante.
>
> 1) La instalación debe resultar trivial como la de cualquier otro
> paquete. Una BD se puede instalar facilmente.
>
> 2) La activación debe ser automática y una buena configuración por
> defecto es suficiente.
>
> 3) El mantenimiento de una BD para un propósito particular no debería
> presentar muchos problemas.
>
> El programa ayuda deberá crear una BD ayuda, un usuario ayuda,
> crear las
> 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. ¿Cómo lo instalo? ¿Estará en la distribución? ¿Cuál
escojo?]
* Pude que el sistema donde se instale la aplicación no tenga
demasiados recursos, o se quieran optimizar.
* Puede que el administrador del sistema no permita tener
aplicaciones "devoradoras" de recursos (y un gestor BD lo es).
La idea de un gestor de BD me parece muy atractiva, que conste. Pero
haciendo de abogado del diablo ... me emociono! };-) .
> > > tecnología no significa que tengamos que usarla. En mi opinión
> eso
> > > sería un error de diseño.
> > >
> >
> > Pero también sería un error deshecharla sin contemplar la
> posibilidad
> > de usarla.
>
> Estoy de acuerdo pero la contemplación de posibilidades que
> supuestamente
> mejoren la aplicación debería hacerse con posterioridad a un diseño
> sólido que contemple totalmente los objetivos principales del
> proyecto.
Ok. La presentación es posterior. Teniendo una buena gestión de la
información, los interfaces serán más o menos complejos pero con la
misma filosofía.
> ...
> Creo que estamos avanzando en la estructura de las tablas a utilizar
> pero creo que la estrutura relacionada con las palabras clave no
> la tenemos nada clara de momento podemos dar por bueno algo
> similar
> a esto:
>
>
> 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 >>).
> 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.
> 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?
> Tampoco tengo claro como establecer las relaciones entre claves.
> Ya hice
> alguna propuesta sobre esto e Ibon Urretavizcaya hizo algunas
> observacionesinteresantes pero son cosas que tienen mucha
> importancia y que no se
> pueden decidir a la ligera. El último modelo fue:
>
> create table claves(
> prev varchar(30) NOT NULL,
> clave varchar(30) NOT NULL,
> post varchar(30),
> tipoclave char(1) NOT NULL, -- 'D|T|A' (D)escript. (T)écnica
> (A)bstracta UNIQUE (clave, prev, post));
>
> Si alguien tuviera experiencia en el diseño de buscadores debería
> orientarnos sobre esto. Hay que tener en cuenta que la forma en
> que se
> guardan esas palabras claves determinará la eficiencia en la
> localización
> de los documentos.
>
Propongo otra posibilidad. Es muy parecida, pero sutilmente diferente
;-).
Creo que tenemos dos "entornos" diferentes: los documentos y las claves
que los describen.
Propongo la siguiente estructura...
LOCALIZACIÓN CARACTERÍSTICAS ABSTRACT
A | |
| | |
|--------- DOCUMENTO ---------|
|
V
CLAVES DOCUMENTO
A
|
CLAVES
|
|
DESCRIPCIÓN CLAVE
donde:
DOCUMENTO
iddoc (C)
versión (C)
fecha-alta *
fecha-modificación *
CARACTERÍSTICAS
iddoc (C)
versión (C)
titulo
autor
tipo-documento
idioma
fecha-documento *
versión-documento *
ABSTRACT
iddoc (C)
version (C)
frase/abstract *
LOCALIZACIÓN
iddoc (C)
versión (C)
url (C)
formato *
fecha-url *
estado-url *
CLAVES DOCUMENTO
iddoc (C)
versión (C)
idclave (C)
peso *
CLAVE
idclave (C)
clave-sucesora (C)
DESCRIPCIÓN CLAVE
idclave (C)
tipo-clave *
descripción-clave *
(C) significa clave en la tabla
* campos "ejemplo", se pueden poner estos u otros.
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
único.
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.
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,... ).
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.
> ...
>
> No vamos a poder empezar a trabajar si no tenemos una estructura
> adecuadapara guardar la información y no tenemos totalmente
> resuelto este tema
> pese a que ya hemos hablado bastante de ello.
>
>
> Un saludo
>
> Antonio Castro
Sigo en mis trece con la idea de que ningún equipo puede parar al otro.
Si el equipo de documentación necesita de un software común/especial,
debería tenerlo. Y si el equipo de programación necesita saber como se
calaloga un documento para definir sus BD, debería saberlo.
Por eso mi "tozudez" al preguntar quienes somos y cuantos.
Empezamos a ver que el proyecto se puede seguir subdividiendo, y ¿no
sería buena idea implicarnos un poco más? Por mi trabajo estoy
acostumbrado a tener una división en equipos clara y casi rígida, y
puede que me esté obcecando demasiado. Pero ... divide y vencerás ¿no?
Por ejemplo: en programación estamos viendo que es buena idea separar
el tratamiento de la información de la presentación. ¿No sería buena
idea "dividir" el equipo de programación en dos? (ES un ejemplo :-) )
Gracias por "soportarme".
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
Reply to: