Bases de datos

From jbermejo@iponet.es Fri Oct 23 00:01:16 1998
To: csn-aplicaciones@onelist.com
Subject: [csn-aplicaciones] Re: Access y bases de datos.

Aprovecho que han salido varios mensajes de Carlos y Manuel para dar algunas opiniones sobre lo que decis y de paso otras opiniones más generales.

Para ser un poco mas sintetico, no cito otros mensajes.

1.-Conversión de tratamiento de textos a Base de datos. Esto lo pregunta Carlos.

Se puede hacer, siempre que lo que hay en el tratamiento de textos esté *estructurado*. O sea, que si yo tengo unos listados en Word o en WPerfect o en simple texto ascii y quiero convertirlos en una Base de Datos, he de tener marcado de algún modo donde empieza y termina cada campo y cada registro. Las técnicas son muchas y el procedimiento concreto dependerá del programa de texto de salida y del de base de datos de entrada. Como no conozco ni Word ni Access, poco puedo decir de los pasos que han de seguirse.

El ejemplo más primitivo es aquel en que tenemos unas listas de personas con sus telefonos

Manuel,2522 Carlos,2911 Jesús,2521 Aris,2231...

La conversión de algo así es obvia: el dbase por ejemplo considerará el salto de línea como indicación de que ahí salta a otro registro. Y las comas definiran donde empiezan y terminan los campos. Si los importamos a una BD con una estructura definida: Nombre, Tfno, -nos metera cada linea en un registro: -dentro de cada registro, lo que hay hasta la primera coma en el primer campo y lo siguiente en el 2º (y asi sucesivamente).

Esto vale fundamentalmente para datos *estructurados*. Si alguien va a trabajar fundamentalmente con *textos* creo que pierde el tiempo con el Access o con Dbase. Otra cosa es que en una base de datos estructurada tengamos campos de texto libre (los famosos campos memo del Dbase).

¿Qué entiendo por base de datos estructurada?. Aquella en que los distintos elementos (registros) siguen una misma pauta: por ejemplo mi base de datos bibliográfica. Ahí tengo incluidos varios miles de referencias de documentos que me pueden interesar por una u otra razon. En principio -tienen un autor (o varios) -tienen un editor -tienen un título. -hablan de unas u otras materias -se editaron en tal año

Todo eso corresponde a *campos* y me va a permitir en su momento recuperar listados por los criterios que yo quiera. Si quiero puedo meter en un campo "memo" o de texto libre las notas que se me ocurran, pero para mí eso es un asunto secundario, porque también puedo referirme en un campo normal a un texto externo y eso a veces es más flexible (tener por ejemplo un campo "anotaciones" en que simplemente anoto cómo se llama el fichero donde estan las notas sobre ese libro o articulo de revista)

El mismo esquema valdría para un fichero de oficina con nombres de clientes, direcciones. O para un inventario de almacen o para contabilidad, etc.. Gracias a que los datos están estructurados vamos a poder decirle: "sacame etiquetas (o un listado) de todos los clientes morosos que nos deben más de 50.000 y con domicilio en Murcia".

O (y este es ejemplo real): hazme un listado de todos los artículos de Carlos aparecidos entre los nºs 5 y 25 de CasiNada. Pero excluyendo los que traten de budismo. Y de paso me los pones en forma TITULO+direccion www para que sea facilmente transformable en una pagina www.

En resumen: si es una base de datos estructurada, siempre habrá manera de traducir datos entre formatos.

Por cierto, por muchas alabanzas que le hagamos al TXT nunca podremos darle darle ordenes como la de los ejemplos que hemos puesto arriba ;-). Las cosas son para lo que son.

Si nuestros datos son no-estructurados tenemos que funcionar de otra manera. Tal vez una base de datos documental (knosys? micro Isis?) tal vez un programa Analisis de datos cualitativos (Atlas/ti?). O bien una base de datos compuesta de textos y un programa que establezca vínculos entre ellos y nos permita organizarlos (Notetab Pro?). O tal vez documentos HTML que contengan nuestros textos, imágenes y vínculos entre ellos.... O soluciones caseras que sean combinaciones de varias de estas.

Si lo que tenemos son *pocos* datos, del tipo que sean... nos vale cualquier cosa.

--Dice Manuel: no conozco a nadie que guarde sus datos en txt y los haya perdido.

Bueno, yo conozco a uno que está tecleando ahora mismo este mensaje y ha tenido problemas de ese tipo. Creo que ni el texto ascii se salva de que algun programa haga de las suyas. Y si no es un programa, pues de que el disco duro se vuelva loco y pegue mordiscos a diestro y siniestro a tus datos (cosa que me paso a mi antes del verano).

Es verdad que los formatos, cuanto más específicos, más delicados. Si un texto recibe un mordisco... no muere para siempre. Pierde la parte que pierde. Si un dbf o el formato que use Access se corrompen... los riesgos de perder todo aumentan.

Bueno, espero no haber dicho demasiadas obviedades. O por lo menos que fueran obviedades tan obvias que se pudieran reconocer rápido y saltárselas uno igual de rápido. :-).

3.-Dice Carlos: "El dbase no tiene cortar y pegar." Bueno, en realidad el DBASE usado en Win, aunque sea la versión III+ (año 1987 creo) que es la que yo uso... tiene cortar y pegar. Eso en el momento en que en programas MS DOS el Windows tambien te deja cortar y pegar. Otra cosa es que por el tipo de datos que yo suelo meter... en realidad no uso nunca eso.

En realidad, como sabes, no es que hable bien del Dbase, es que llegue a conocerlo algo, incluyendo su lenguaje de programación (y el del Clipper, en gran parte el mismo). Y me es cómodo no tener que aprender nada para el tipo de cosas que le pido.

Supongo que si empezara de cero no se me ocurriria ponerme con el DBaseIII+. Aprenderia a usar Access o Paradox o Filemaker, que creo que en realidad hacen tantas cosas como el Dbase, ademas de poder incluir imagen, etc. Y si fueran bases de datos documentales, pues alguno de los apuntados arriba, probablemente Micro Isis, que ademas es gratuito, usa mucha gente, hay documentacion en español y aunque viene de MS DOS han sacado recientemente una version Windows. En realidad ese sirve para ambos tipos de bases de datos.

Pero no me preguntéis nada sobre el, que no se nada. Lo tengo desde hace un año y no lo he instalado, porque no creo necesitarlo ahora mismo. En este momento, con la suma Atlas/ti+ ficheros de texto+Dbase tengo de sobra.

Sospecho que en el futuro, si cuaja el formato XML, van ampliarse mucho las posibilidades. Porque vamos a tener un formato flexible que en realida es texto puro (como el html) solo que con unas marcas en que vamos a poder definir "lenguajes" y tipos propios de documentos con características de base de datos adaptada a nuestras necesidades. Y encima con un estándar público, nada de formatos propios de una marca.

saludos, Jesús.