Regístrate | Conectar
El Tamiz Libros Recursos Series Únete 20 Users Online
Skip to content

Historia de un Viejo Informático. El camino hacia las Bases de Datos Relacionales.




En la entrada anterior vimos cómo comenzaron a usarse los PC’s en la empresa (y poco después en todos lados). Otro de los hitos tecnológicos que tuvieron lugar a mediados de la década de los ochenta del siglo pasado fue la irrupción en el mercado de las Bases de Datos Relacionales, sin las que hoy en día no podríamos entender la informática, y a relatar cómo comenzaron a ser lo que hoy en día son me voy a dedicar en esta entrada y la siguiente.

En esta entrada de hoy, sin embargo, y por razones de espacio, no voy a hablar de Bases de Datos Relacionales, de las que sí que hablaré en la próxima, sino que me centraré en los antecedentes: daremos un repaso a la historia de las Bases de Datos, mejor dicho, de los Sistemas de Gestión de Base de Datos que existían en el momento (sobre 1984-85). Es más, comenzaremos incluso antes, por conocer cómo eran las técnicas de almacenamiento de la información antes de que existieran las Bases de Datos (de cualquier tipo), o cuando sí que existían, pero, debido a sus limitaciones, no se podían usar…

Como la serie tiene ya unos pocos artículos, en esta dirección encontraréis el enlace a todos los artículos publicados hasta ahora.

Los primeros ordenadores sólo eran capaces de procesar una clase de ficheros: los secuenciales. Es decir, un conjunto de registros de información guardados todos juntos, uno detrás de otro, y que se leían o escribían también de uno en uno, uno tras otro, hasta acabar todo el conjunto.

Los primeros ficheros informáticos fueron en tarjeta perforada (ya la máquina de Hollerith para el censo de 1890 funcionaba con ellas). Un fichero en tarjetas perforadas es un bloque de tarjetas que tienen perforaciones que representan los caracteres que componen la información del registro. Los bloques de tarjetas se procesaban todos completos: se comenzaba a leer desde la primera tarjeta hasta alcanzar la última. Por tanto, si por algún motivo era necesario acceder exclusivamente a un registro, se debía leer secuencialmente todo el bloque, desde el principio, hasta llegar a él.

En esta nostálgica entrada, gracias a Jaume, os mostré cómo era un programa Cobol en tarjetas perforadas. Para que os hagáis una idea, un fichero en tarjetas perforadas es la misma cosa, sólo que las tarjetas tendrían todas la misma estructura, y en ellas habría grabados datos, no programas.

Unidad de Cinta IBM 2420 (años 60)

Unidad de Cinta IBM 2420 (años 60)

El soporte fue evolucionando. Primero, cinta perforada, heredada directamente del telégrafo, que es para las tarjetas lo mismo que los rollos de papiro en que los antiguos griegos escribían sus tratados, a los códices  encuadernados en que los copistas medievales copiaron los escritos originales (los pocos que sobrevivieron, desde luego).

Después, a partir de principios de la década de 1950, fue la cinta magnética la que tomó el relevo… y esta vez para quedarse. Una cinta de 2.400 pies, la habitual a partir de los sesentas, grabada a 1600 ppi (phrames per inch, o caracteres por pulgada) podía almacenar unos 50 Mb de información… cuando los carísimos discos de la época podían almacenar quizá tres o cuatro… Las cintas magnéticas actuales almacenan Gigas y Gigas a un coste ridículo.

La aparición de la cintas magnéticas supuso un cambio sustancial en la forma de diseñar aplicaciones: ahora era posible mantener un fichero maestro (digamos, de Cuentas Corrientes) y diariamente acumular en otra cinta los movimientos del día, y entonces, leyendo simultáneamente ambos ficheros (¡el omnipresente padre-hijo!), escribir en una tercera cinta magnética el fichero maestro actualizado.

Este proceso igual podría hacerse en ficha perforada… pero es que, además de lento… ¡era carísimo! Las tarjetas perforadas no son reutilizables (una vez perforadas, no se pueden des-perforar…), mientras que las cintas sí que lo son: se pueden leer y escribir una y otra vez sin merma en su funcionamiento (al menos durante mucho tiempo).

.

Publicidad de Discos en 1977. ¡Obsérvese el precio!

Publicidad de Discos en 1977. ¡Obsérvese el precio!

Pero, con la aparición de los discos magnéticos (a finales de los cincuenta), la situación comenzó a cambiar. Porque con un disco magnético es posible algo que con una cinta no lo es: acceder a un registro determinado de un fichero sin necesidad de leer previamente todos los registros anteriores, simplemente dando instrucciones a la cabeza lectora de qué área del disco leer. Y lo mismo con la grabación. Esta característica abría nuevas posibilidades, que al poco se comenzaron a explotar.

Para que un programa supiera en qué dirección física del disco se encuentra la información demandada (supongamos la cuenta número 1537), antes había que haber anotado, en algún sitio, en el momento de la escritura, la dirección física donde había ido a parar tal cuenta.

Una solución obvia es utilizar el propio número de cuenta como dirección a la hora de grabar. Así, la cuenta 1537 estaría en la dirección 1537, y localizarla es inmediato.

Pero, claro, quizá la numeración de las cuentas no permita esta solución, por ejemplo, porque el propio número incluya el tipo de la cuenta, o porque tengan muchos huecos de numeración entre las cuentas (porque las cuentas adyacentes a la 1537 fueran la 1459 y la 1703, por ejemplo, con lo que se desaprovecharía muchísimo espacio). En la práctica, casi nunca puede usarse tal tipo de direccionamiento, salvo para ficheros-tabla de códigos, que tienen relativamente pocos registros y son muy estables en el tiempo.

Una forma de solucionar esto sería con la aplicación de una fórmula matemática que convirtiese el código del registro a buscar a una dirección física y unívoca. Esta técnica implica usar una función hash, y es muy eficiente… en los casos donde es factible usarla, que tampoco son tantos.

Así que rápidamente se constató que la única forma eficaz de poder conocer la dirección física de un determinado registro de un fichero era mediante la utilización de índices.

Un índice consiste ni más ni menos que crear, simultáneamente a la creación del fichero que se pretende indexar, otro fichero diferente al principal, que contendrá, ordenadas, las claves de acceso junto con sus direcciones. Así, tendríamos que nuestras cuentas estarían representadas, por ejemplo, con registros que podrían decir: 1459-007; 1537-008; 1703-009… Es decir, la cuenta 1459 está ubicada en el bloque 007, la 1537 en el 008, etc.

Ahora, para poder acceder a la cuenta 1537, basta con leer el fichero de índices (mucho más corto que el principal) hasta determinar la dirección de la cuenta y entonces ir al fichero principal, con un acceso directo, a dicha dirección. Es más, si es posible, mantendremos en memoria principal el fichero de índices, agilizando muchísimo el acceso (pues evitamos siquiera leer el índice).

Pero los propios índices pueden resultar de buen tamaño, así que se crea a su vez un índice para el propio índice, y así sucesivamente hasta llegar a un tamaño de índice razonable para mantener en memoria, creando así un árbol de índices. En realidad las cosas son un poco más complicadas de lo que he explicado aquí, pero creo que para hacerse una idea es suficiente… y los que ya conocéis todo esto… pues eso: ya lo conocéis.

Típico árbol de índices

Típico árbol de índices

Ya desde el advenimiento del Cobol en 1960, se incluyó la definición y tratamiento de ficheros indexados (ORGANIZATION IS INDEXED, mediante diversas cláusulas de definición y extensiones a las sentencias de lectura y escritura), y esto permitió diseñar las primeras aplicaciones con acceso directo a la información (en inglés se llama acceso Random, es decir, aleatorio, pero en realidad no es aleatorio en absoluto, sino que tu programa decide a qué registro acceder en función de la información solicitada). Y las aplicaciones que típicamente necesitan acceder a información de esta forma son las Aplicaciones Online. Es decir, si el Online existe es ni más ni menos gracias a la existencia de los índices…

…Porque lo interesante de todo esto es que el acceso mediante índices ha sido, y sigue siendo el método utilizado por todas las Bases de Datos de todo tipo para acceder a la información.

Utilizando ficheros secuenciales indexados, se pudo empezar a desarrollar las incipientes aplicaciones online, aunque hasta que no se dispuso de Gestores de Teleproceso era realmente difícil programar estos sistemas (que, además, tenían muy poca capacidad: a los exiguos tamaños de memoria y procesador existentes, se añadía la mínima velocidad de las líneas telefónicas de entonces: punto a punto, a 1200 o 2400 baudios –bits por segundo-).

Una curiosidad: uno de los primeros Monitores “serios” de Teleproceso (anterior en varios años al CICS de IBM), fue el PCL. El acrónimo PCL significa Programa de Control de Líneas (en español, sí), dado que fue desarrollado en el laboratorio de IBM en Barcelona, por un equipo dirigido por el holandés Rainer Berk, bajo las especificaciones del cliente, y trabajando codo a codo con ellos, y que se instaló por primera vez en La Caixa d’Estalvis i Pensions, alrededor de nada menos que 1964.

Este programa, que fue evolucionando y mejorando con los años, se usó durante los primeros tiempos en todos los bancos españoles que empezaron a hacer pinitos con su teleproceso en la década de los sesenta y primeros setenta, pues hasta al menos 1970 ó 71 no comenzó IBM a ofrecer CICS en España (e IMS/DC es posterior en cinco años o más).

No esperéis un link a algún artículo de la Wikipedia hablando de PCL, ni algún link a algún otro sitio hablando de PCL… ¡No hay! Es como si nunca hubiera existido. Fue un hito español en informática… y prácticamente nadie lo conoce, ni se encuentra documentación, aparte de en la memoria de algunos viejos rockeros. Y, aunque no tanto, lo mismo sucede, por ejemplo, con otra gran innovación española de la época (además, ésta fue completamente española): la Red Especial de Transmisión de Datos (RETD), que fue la primera red mundial de transmisión de paquetes, y sobre la que también ha caído el olvido, aunque afortunadamente Jesús Martín Tardío (ingeniero de Telefónica de aquellos años) ha escrito un maravilloso relato de lo que pasó esos años gloriosos.

Ignoro si será exclusivamente tradición española la de ignorar (o peor, ¡despreciar!) las cosas buenas que se han hecho y magnificar las malas, pero indudablemente eso ocurre, y hay muchísimos ejemplos. Uno flagrante (que no tiene nada que ver con ordenadores):

¿Sabéis quién fue el Almirante Nelson? ¿Sabéis quizá qué pasó en la batalla de Trafalgar, en 1805? Quizá os suene de algo…

Sí, ya veo que sí. Y… ¿Sabéis quién fue el Almirante Blas de Lezo? ¿Sabéis por ventura qué ocurrió en el Sitio de Cartagena de Indias sesenta años antes, en 1741? Pues cuando lo leáis, si lo leéis, igual os lleváis una sorpresa…

.

Volvamos a los ficheros indexados…

Efectivamente, su capacidad de recuperar o grabar la información mediante un acceso directo, sin necesidad de leer el fichero completo, permitió el advenimiento de las primeras aplicaciones online… pero si las aplicaciones en sí eran posibles, en realidad tenían muchas dificultades para su normal explotación diaria.

Una de ellas era la dificultad para organizar los accesos concurrentes, es decir, la gestión de los bloqueos. En un proceso bancario, por ejemplo un pago de cheque, es normal acceder primero a la cuenta para ver, lo primero, si existe, y después, si tiene saldo suficiente para hacer frente al cheque, luego a los talonarios de la cuenta para comprobar que el cheque existe y no está bloqueado por algún motivo, etc. Al final de todas las comprobaciones, se marca el cheque como pagado, se actualiza el saldo de la cuenta, y se graba el movimiento para su contabilidad.

Si todo va bien, no pasa nada. Pero puede ocurrir que otra transacción que se ejecuta en la región de al lado (que para algo habíamos inventado ya la multiprogramación), pretenda pagar un recibo de la misma cuenta en el mismo momento. Si no se controla muy bien, y se obliga a la segunda a esperar a que la primera termine, se puede montar un carajal de mucha consideración. Con los ficheros indexados, todo este montaje hay que controlarlo a mano, complicando enormemente la programación… en unos ordenadores que, recordad, sólo tienen unas pocas Kbs de memoria…

Pero la otra es aún más seria: Ante un error de hardware o de programa (que, a veces, cascan ¿sabéis?, por muy bien escritos que estén) el fichero indexado se queda hecho unos zorros. Como en realidad se mantienen dos ficheros a la vez, el de índices y el de datos, es muy posible (es más: era lo normal) que el fallo deje actualizado uno de ellos, pero no el otro… dejando el fichero inservible. Entonces, la única alternativa era asumir que el contenido del fichero principal (los datos) es el correcto, y a partir de él reconstruir los índices… utilizando el fichero en exclusiva durante el tiempo que dure el “rebuild” (y rezar porque todo acabe bien y no haya que volver a la versión anterior, perdiendo toda la sesión online hasta el fallo). O sea, parando la aplicación online mientras se recupera. Bastante inaceptable, como podéis suponer.

Charles Bachman

Charles Bachman

Otro de los gurús de la informática, Charles Bachman, estuvo en la génesis de la solución a todos estos problemas: el concepto de “Base de Datos”.

De sus trabajos nació la primera Base de Datos de la historia: IDS, de General Electric (una de las grandes compañías mundiales, también en informática; de hecho durante los años sesenta era uno de los así llamados “Siete Enanitos”, las siguientes siete mayores compañías de informática que competían en el mercado con la madrastra, IBM…, hasta que decidió abandonar el negocio en 1970, vendiendo la división de informática a otro de los enanitos: Honeywell).

La idea fundacional de las Bases de Datos (en realidad, de los Sistemas Gestores de Bases de Datos) era solventar todos los problemas derivados del uso aislado de los diferentes ficheros, no tanto pensando en el batch (que, en realidad, estaba resuelto sin necesidad de Base de Datos alguna), sino para dar soporte a los emergentes procesos online y de tiempo compartido.

Un DBMS debía, en primer lugar, asegurar la coherencia de los datos en todo momento. Esta es una conditio sine qua non para poder desarrollar y explotar con éxito una aplicación online. Y además debe permitir interactuar con ella a desarrolladores, técnicos de sistemas, etc con cierta sencillez, para facilitar el desarrollo, explotación y posterior mantenimiento de las aplicaciones. Resumiendo, un DBMS (de cualquier tipo, por cierto, incluido uno Relacional) que se precie debería, al menos, de cumplir las características siguientes:

1 Ante un fallo de un programa, debe ser capaz de recuperar la información que éste se encontró, deshaciendo todos los cambios realizados antes de su fallo. Esto implica la existencia de un log de cambios donde quedan reflejados todos los cambios efectuados por el programa, y que permiten deshacerlos para volver a la situación original.

2 Debe ser, además, capaz de recuperar un proceso completo que haya resultado erróneo, aunque haya terminado aparentemente bien (o sea, que no ha cascado). Por ejemplo, puede que un determinado proceso batch haya funcionado mal, y actualizado erróneamente muchos registros, o todos; el Gestor debe permitir recuperar el proceso completo para repetirlo una vez arreglado el programa fallón. Esto exige una gestión avanzada de copias de seguridad, coordinada con la propia gestión del log.

3 Debe proporcionar un procedimiento robusto ante fallos del propio sistema. En el caso de un error en una Base de Datos, debe permitir recuperar la que esté afectada, sin necesidad de afectar el resto; de esta manera se independizan unas aplicaciones de otras.

Concurrencia de Procesos

Concurrencia de Procesos

4 Debe gestionar de forma eficaz la concurrencia entre procesos. Esto exige un control automático y eficaz de los bloqueos: cuando un programa accede a un registro de la Base de Datos con la intención de actualizarlo, el DBMS debe dejarlo bloqueado para cualquier otro proceso, hasta su terminación (correcta, en cuyo caso los cambios se consolidan, o errónea, en cuyo caso se deshacen).

Para lograr todo esto se requiere que el lenguaje de interfaz con la Base de Datos permita avisarla de que el programa tiene intención de actualizar el registro que está solicitando para lectura; que yo sepa toda Base de Datos tiene esta función (como las peticiones tipo “GHU” en IMS, o la “SELECT FOR UPDATE” en SQL).

Cuando se produce concurrencia, la estrategia correcta no es precisamente la del “avestruz”, sino dejar en espera al segundo peticionario que llegó, hasta que el registro bloqueado quede liberado, y entonces permitirle continuar su proceso. Pero este mecanismo también tiene sus problemas…

Deadlock de procesos

Deadlock de procesos

5 …Porque en caso de que dos transacciones requieran registros cruzados (lo que en la literatura técnica se conoce como “deadlock”, o, en cheli, el abrazo del oso), o se resuelve de alguna manera, o quedarán bloqueados ambos registros… para siempre. Un proceso P1 requiere el registro B, y lo bloquea, y después el registro A, mientras que otro proceso P2 requiere el registro A, y lo bloquea, y después el registro B (estas cosas se dan con más frecuencia de lo que podría parecer). Si hay la mala suerte de que ambos procesos, ejecutándose simultáneamente, han obtenido sin problemas sus primeros registros… tenemos un problema. Porque el proceso P1 tiene bloqueado el registro B y está a la espera del A… que está bloqueado por el proceso P2, que a su vez está esperando el registro B. Si el DBMS no reconoce el problema para ponerle solución (típicamente calzarse uno cualquiera de los dos procesos, para dejar que uno al menos, el otro, termine bien, y después relanzar el proceso abortado), podría colapsarse y requerir intervención manual, lo que no parece muy buena idea. El Gestor de Bases de Datos debe solventar los deadlocks cuando ocurren. Además, este caso puede darse no sólo con dos procesos, sino con tres, cuatro… lo que es bastante complicado de resolver.

6 Las bases de datos deben proveer un interfaz para que los programadores puedan codificar correctamente los accesos, en lectura o actualización, o la navegación entre diferentes registros relacionados; interfaz documentado y único, y a ser posible que libere al programador de todas las funciones de control, gestión de los índices, de los punteros, los backups o recoveries, etc. Deben proveer también toda una serie de programas de utilidad para todas las tareas técnicas, como reorganización, creación de índices, etc.

7 Y además… deben permitir al usuario (el usuario de estas Bases de Datos era el programador, no el usuario final) la abstracción del modelo físico: es decir, se diseña el modelo lógico de la información, cómo son las entidades de datos y cómo se relacionan entre sí, y se plasma en el propio diseño de la Base de Datos. Naturalmente, esto cambió, con el tiempo, la propia forma de diseñar las aplicaciones, dando origen al poco tiempo al nacimiento de las metodologías de Diseño Estructurado, el modelo Entidad-Relación, etc. Pero ésa es otra historia, y será contada en otro momento.

Todas estas características están resumidas (más o menos) en lo que se conoce como ACID: Atomicidad, Consistencia, Aislamiento, Durabilidad.
.

Podemos decir que las Bases de Datos cumplieron sobradamente sus objetivos, desde el primer momento. Doy fe. Evidentemente, las primeras de ellas no eran sencillas ni de diseñar ni de programar correctamente (bueno, si nos ponemos quisquillosos, tampoco ahora, je, je), pero efectivamente eran razonablemente seguras, rápidas y eficaces, cuando se rompían, se arreglaban bien y rápido, y, aunque complicadas de programar, lo eran mucho menos que si hubiera habido que hacerlo directamente con los ficheros indexados.

Programar para IMS era bastante complicado. Lo sé: yo lo hice. Lidiar con las PSBs, las PCBs, las SSAs, etc, necesita de mucha, pero mucha, atención por parte del programador (y conocimientos, desde luego), y tener siempre presente el diagrama del diseño físico de la Base de Datos.

Aún recuerdo una transacción que tenía un tiempo de respuesta normal (pequeño), y ante una (aparentemente) mínima modificación, de pronto se convirtió en la transacción que más recursos consumía de todo el Banco. Resulta que la modificación obligaba al IMS a recorrer toda una larguísima cadena de gemelos (las distintas ocurrencias de un mismo segmento) para insertar el suyo… y nadie nos dimos cuenta de ese hecho (ni el Analista -yo, y mira que sabía yo de IMS por entonces-, ni el programador, que sabía también lo suyo, ni el Técnico de Sistemas…). Para solucionarlo, se añadió un nuevo puntero al segmento padre que apuntara a la última ocurrencia del segmento hijo (el puntero PCL, por “Phisical Child Last”)… y el programa ahora solicitaba directamente el último segmento, antes de insertar. Un éxito: la transacción volvió a ser de las más modositas de la instalación. Esta anécdota tontorrona puede ayudar a haceros una idea de lo fino que había que hilar.

Base de Datos Codasyl

Base de Datos Codasyl

A raíz de los esfuerzos de Bachman, se creó en CODASYL un grupo para definir las características y especificaciones que debían cumplir las Bases de Datos en Red; estas especificaciones se publicaron en 1969 y permitieron el avance de la industria de las Bases de Datos.

Aunque algunos, como IBM, habían avanzado por su cuenta, y ya tenían en el mercado la suya propia (IMS) desde 1968, ya que fue diseñada para poder gestionar el complicadísimo control de inventario del Programa Apolo (ése que hizo que Armstrong, Aldrin y compañía pisaran la Luna… aunque todavía hay quien lo duda).

Comenzaron a aparecer en el mercado diferentes bases de datos, que implementaron, unas más y otras menos, los estándares CODASYL: unas fueron concebidas como bases de datos en red, y otras fueron diseñadas como jerárquicas; el modelo jerárquico (que admite sólo relaciones de padre a hijo, y entre gemelos) no es más que un modelo en red restringido, y por tanto estaba también contemplado en las especificaciones CODASYL.

Diagrama de Base de Datos en Red

Diagrama de Base de Datos en Red

En esta página tenéis una recopilación de las Bases de Datos de todo tipo que se habían creado y/o comercializado… antes de 1986, antes de la explosión relacional. Hay unas pocas: ¡Más de 150!, y aunque en puridad algunas de ellas no son en realidad Bases de Datos, sino más bien sistemas de acceso a ficheros, o aplicaciones escritas sobre una Base de Datos, os podéis hacer una idea del gran follón “basedatísitico” que había.

Casi cada fabricante importante construyó y vendió la suya, y aparecieron bastantes empresas independientes de software que construyeron y vendieron sus propias bases de datos (probablemente debieron ser de las primeras empresas que construyeron software básico sin ser fabricantes de hardware).

A la primera de todas, IDS (de GE, luego Honeywell), le siguieron (además de IMS, de IBM), DMS1100 (de Sperry Univac), DMS II (Burroughs), IDS2 (Bull), IDMS (Cullinet, luego Computer Associates), Total (Cincom), Datacom (ADR, luego Computer Associates), Adabas (Software AG), System 2000 (De una tal INTEL -antes MRI-, que no es la misma Intel que todo el mundo conoce; yo juraría que en España la vendía Siemens, para sus ordenadores Siemens 4004, aunque no lo puedo asegurar), etc, etc, etc.

Estas tres últimas se basan en el concepto de “listas invertidas” que proporciona un excelente tiempo de acceso en lectura, aunque no precisamente en actualización, lo que las hace especialmente eficientes en entornos de sólo-consulta, con poca o nula actualización. Adabas, en concreto, sigue siendo utilizada en grandes instalaciones españolas (y de todo el mundo) después de su “lavado de cara” relacional de hace ya bastantes años (admite SQL como interfaz), aunque buena parte de la culpa de que siga estando vigente la tiene Natural, también de Software AG, el único lenguaje de Cuarta Generación que de verdad tuvo éxito, que funciona muy bien con Adabas (y con DB2, y con Oracle…), y que se mantiene funcionando en la actualidad… pero esa es otra historia, y será contada en otro momento.

Esto de las listas invertidas puede parecer antiguo, pero sigue siendo muy usado en la actualidad: por ejemplo, los buscadores que se usan en aplicaciones web, incluyendo el todopoderoso Google, utilizan variaciones de listas invertidas para realizar las búsquedas (necesitan muy buen tiempo de acceso en lectura, pero no tanto en actualización).

Desde luego, los nombres de la mayoría de Bases de Datos de la época parecían una sopa de letras. Tanto, que en aquéllos tiempos gloriosos, no podíamos evitar, entre los enteradillos de la profesión, contarnos el siguiente chiste (que entonces tenía mucha más gracia que ahora, por cierto):

tendero-con-cliente

En una tienda:

Cliente (señalando): Déme ése. Y déme ése. Y de ése… y de ése, dos.

Tendero (a la cajera): Déle uno. Total, debe dos.

…Ya, ya dije que no tenía gracia… Mejora un poco si lo ponemos en su contexto:

Cliente: DMS. IDMS. IDS…IDS2.

Tendero: DL/1. Total, DB2.

En fin. A Adabas no había forma de meterle en el chascarrillo…

Desde luego, la propia sobreabundancia de versiones de Bases de Datos de todos tipos y colores a finales de los setenta ya quiere decir mucho: Tuvieron un gran éxito, y cumplieron con las expectativas más halagüeñas. Efectivamente resolvieron aquellos problemas que vinieron a resolver: Las aplicaciones fueron mucho más fiables, los datos mucho más coherentes, el proceso de diseño de los datos, más estructurado y lógico, y ante un fallo de cualquier tipo, la información se recuperaba normalmente de forma rápida y completa, sin pérdida alguna.

Pero tuvieron también inconvenientes, algunos de ellos bastante importantes, que abonaron el cambio de tecnología de mediados y finales de los ochenta.

En primer lugar, cada Base de Datos era de su padre y de su madre. Literalmente. Cada una de ellas tenía un lenguaje de definición, un modo de ejecución, diferentes programas de utilidad, y, por supuesto, diferente interfaz para los programas de aplicación. La forma usual es resolver los accesos mediante la llamada (vía CALL, generalmente estática) a un determinado módulo del gestor (en el caso del IMS de IBM, por ejemplo, el módulo es CBLTDLI desde Cobol, ASMTDLI desde Assembler, etc), con ciertos parámetros que le indican a qué Base de Datos se quiere acceder, a qué segmento o entidad, y para hacer qué (leer el segmento de cierta clave, o el siguiente en secuencia, o modificar el segmento con nuevo contenido, borrarlo…).

Hay que tener en cuenta que todas las Bases de Datos de la época eran Navegacionales, sin excepción, es decir, era el programador el que indicaba el orden de recuperación de la información en la Base de Datos: primero recuperar un segmento padre con una clave dada, luego recuperar la primera ocurrencia de uno de sus segmentos hijo, leer en secuencia todos estos segmentos hasta cumplir cierta condición, reescribir el segmento, insertar un nuevo segmento al final de la cadena, saltar a otro lugar distinto, y así hasta acabar el proceso, tanto en batch como en online.

Y en cada Base de Datos este proceso es distinto, pero no un poco distinto, sino completamente diferente. Migrar de una a otra Base de Datos requiere no sólo efectuar un proceso complicado de descarga de la información y carga en la nueva Base de Datos, que en realidad era lo más sencillo, sino que había que reprogramar completamente todos los accesos… para lo cual había, en primer lugar, que dar un completo Plan de Formación a todo el personal, y luego, reprogramar la Aplicación completa.

Portabilidad: brillaba por su ausencia...

Portabilidad: brillaba por su ausencia...

En una palabra: No existía portabilidad entre Sistemas. Ni la más mínima. Quizá esto no fuera un problema muy serio para las instalaciones de cliente (tampoco vas a andar cambiando de Sistema a cada rato), pero era un inconveniente importantísimo para los fabricantes de Software de Gestión.

Supongamos que hemos desarrollado una Aplicación que queremos vender a muchos clientes, por ejemplo una Nómina. Inicialmente la desarrollamos en, digamos, un mainframe IBM con IMS, que para algo tiene la mayor cuota de mercado. Cuando está lista, la empezamos a vender (bueno, antes de que esté lista… que el marketing es el marketing).

Y aunque haya una base importante de clientes para nuestra Nómina, resulta que no todos los clientes tienen esa configuración. Los hay que tienen un mainframe de IBM, pero la Base de Datos es Total, o Datacom, por ejemplo. Otros grandes clientes tienen un Siemens 4004 con System 2000, o con Adabas. Y otros, un Bull con IDS2. Migrar la aplicación para que corra simultáneamente, con las mismas funcionalidades, en todos estos sistemas y Bases de Datos es… una locura. Migrar una aplicación de Unix a Windows o viceversa es un juego de niños, comparado con lo que era migrar de IBM/IMS a Digital/Adabas… ¡Y eso que al menos, el Cobol sí que era el mismo!

De hecho, la fragmentación de la tecnología, más exactamente, la diversidad de diferentes interfaces con los Sistemas, redujo muchísimo el alcance del incipiente mercado del software independiente durante las décadas de 1960, 70 y casi todos los ochenta del siglo pasado. Cosa que a los fabricantes de hardware no les preocupaba en absoluto, como es obvio: así, su mercado era cautivo. A los fabricantes de cualquier cosa les encantan los mercados cautivos

Y, además de esta falta de estándares, es que tampoco era nada sencillo diseñar y programar bien para ninguno de estos Sistemas y Bases de Datos. En igualdad de condiciones, era mucho más sencillo que hacer lo mismo a pedal, directamente con ficheros indexados, desde luego que sí, pero seguía siendo difícil… mayormente porque la propia existencia de las Bases de Datos permitió la realización de Aplicaciones con una complejidad muy elevada, que hubieran sido completamente imposibles sin esas Bases de Datos.

Se requería una muy buena formación, apoyo constante en manuales (había tal cantidad de opciones y posibilidades que necesitabas consultar los formatos de las llamadas constantemente), y experiencia. Y lo primero se solventaba con cursos de formación, por caros que fueran (que lo eran), lo segundo con una buena fotocopia del original para cada uno… pero la experiencia sólo se conseguía con tiempo, y aprendiendo de las galletas, sobre todo de las propias, que ya sabemos que nadie escarmienta en cabeza ajena. Es decir, los buenos técnicos (analistas, programadores, técnicos de sistemas) escaseaban. Mucho.

Se los reconocía porque, cuando hablaban, nadie en absoluto a su alrededor que no fuera de la profesión entendía una palabra. Y a veces, ni así. Por ejemplo:  ”Hemos tenido un 0C4 en una región del VSAM, y el PTF del CAS no pudo instalarse porque la versión del HSM no estaba a nivel…” Ya me diréis lo que entendía nadie de todo eso, y sobre todo, ya me diréis qué entendía el pobre usuario (por ejemplo, el responsable de préstamos de la sucursal de Antequera) cuando llamaba, medio llorando, para decirte que no podía abrir un préstamo hipotecario porque la máquina no le dejaba… y recibía semejante contestación.

Aquí estábamos muchos

Aquí estábamos muchos

Esta escasez de buenos profesionales trajo dos consecuencias, buenas o malas (según se mire): Se activó el mercado para estos profesionales (para nosotros, vaya), que comenzaron a cambiarse de empresa, explotando su conocimiento tan exclusivo y valorado, y por consiguiente se comenzaron a mover los sueldos, no sólo en las empresas que fichaban nuevos empleados, sino también en las que pretendían conservar los suyos… o sea, en todas. Y este movimiento salarial fue bueno para nosotros, los informáticos del momento. Ganábamos bastante dinero. Trabajábamos mucho, eso es cierto también, pero el sueldo era muy bueno, y nosotros éramos buenos, importantes, imprescindibles…

… Y nos endiosamos.

Sí, lo reconozco. Lo sé de buena tinta porque yo también fui un dios… Tan importantes nos sentimos, tan insustituibles, tan necesarios… que nos volvimos unos perfectos cretinos. Nos olvidamos de lo más importante (de lo único importante): que no somos ni más ni menos que un Departamento de Gasto, es decir, que el resto de la empresa nos ve como Un Mal Necesario. Y, encima, ¡caro!.

Nosotros, los informáticos, no generábamos un duro para el negocio: eran los sufridos comerciales, gestores y administrativos los que ganaban con sus ventas y su trabajo día a día el dinero suficiente como para pagar no sólo sus sueldos, sino los de los informáticos, y los de todos los demás, así como los dineros que se reparten a los accionistas.

Sigo reconociéndolo: Nos encastillamos en nuestra torre de marfil, y llegamos a pensar que lo único importante era que nuestros sistemas fueran como la seda (desde nuestro punto de vista, eso sí), que el tiempo de respuesta fuera bueno, que no fallaran las aplicaciones y, sobre todo, que nos molestaran lo menos posible con peticiones, cambios, problemas y demás zarandajas.

Las peticiones de cambio en alguna aplicación por parte del usuario, que hasta hacía poco habían sido atendidas con prontitud, comenzaron a ser sistemáticamente distraídas, retenidas, paradas, cortocircuitadas… Las excusas eran… bueno, eran para estar allí y oírlas, verbigracia:

Bla, Bla, Bla...

Bla, Bla, Bla...

Mira: para hacer esta modificación que pides, debo convertir un índice Phisical-Child-First en un Phisical-Child-Last, con lo que debo modificar cuarenta y cinco transacciones y treinta y siete programas batch, hacer un REORG y parar la Base de Datos una semana y media, y además las transacciones de consulta por LTERM tendrían un tiempo de respuesta mucho peor que ahora porque se produciría un encolamiento estocástico masivo, y afectaría al rendimiento ciclotímico del sistema transversal del VSAM, y bla bla bla…”.

…Y el pobre usuario, compungido y desarbolado, te pedía perdón por habérsele ocurrido semejante proposición deshonesta, te invitaba a un café como desagravio… y se volvía a sus Cuarteles de Invierno completamente frustrado, porque en realidad él o ella sigue pensando que poder sacar los movimientos de las cuentas ordenados por fecha de valor en vez de por fecha de operación no debería ser tan complicado…

Las aplicaciones se complicaban más y más… costaban más y más… y cada vez estábamos más lejos de los usuarios. Los árboles no nos dejaban ver el bosque. Y al final lo pagamos. Pero ésa es otra historia, y será contada en otro momento.

Yo creo que de esta época (principios y mediados de los ochenta) fue cuando empezó a aparecer ese sano odio que la mayoría de usuarios de las empresas (no sólo las grandes) tenían y siguen teniendo a los informáticos. Claro que a lo mejor es completamente natural el sentimiento de unos y de otros, porque es cierto que hoy por hoy, sin su informática, casi ninguna empresa sería viable, pero más cierto aún es que, sin su empresa, casi ningún informático sería viable.

Yo, por mi parte, siempre intenté dar en lo posible el mejor servicio a mis atribulados usuarios, ponerme en su lugar, y mantener las aplicaciones lo más adecuadas y fáciles de utilizar posible, eso que ahora se llama usabilidad. Pero también he de entonar el mea culpa, pues soy culpable de una buena parte de los pecados descritos. Muchos años después, he de reconocer que una parte de los de la profesión sufrimos (en pasado) y aún sufrimos (en presente) esta enfermedad.

Si mis pobres palabras sirven para que algunos de vosotros, queridos lectores informáticos, reflexionéis un poco sobre esta circunstancia, habrán cumplido su misión. Y os pido humildemente perdón, si en algo os he ofendido

Volvamos ya a las Bases de Datos, que esto va de Base de Datos, no de golpes de pecho…

.

Ya a principio de los setenta, había algunos adelantados que pensaban que esta generación de Bases de Datos podría abocarnos, con el tiempo, a un callejón sin salida.

Era necesario un método de diseño más sencillo, pues cada vez más y más aplicaciones se escribirían en todo el mundo y no era conveniente que todas y cada una de ellas necesitaran unos técnicos especializados y muy expertos, cada uno de ellos en un producto diferente e incompatible con el resto. Era necesario solventar la falta de compatibilidad entre aplicaciones mediante un interfaz común. Era necesario encontrar alguna cosa, algún sistema para facilitar la elección del mejor camino para recuperar la información pedida sin necesidad de tener que conocer de antemano (y programar cuidadosamente) el mejor camino para hacerlo, es decir, realizar la navegación de forma automática. Era necesario que un simple cambio en la definición de la Base de Datos no obligara a modificar todos los programas que acceden a ella. Era necesario, por fin, depender cada vez menos los informáticos.

En una palabra, era necesario volver a acercar la tecnología al negocio, porque en los últimos tiempos ambos se estaban separando cada vez más, y la pinta era que podrían llegar a perderse de vista…

En el próximo capítulo seguiremos la historia contando, cómo no, el advenimiento de las Bases de Datos Relacionales, cómo comenzaron y cómo lograron con los años el cuasi-monopolio que ostentan en la actualidad, mientras vuestra indulgencia (¡y la de Pedro!) me lo permitan.

Disfrutad de la vida, mientras podáis.


Sobre el autor:

Macluskey ( )

Macluskey es un informático de los tiempos heroicos, pero no ha dejado de trabajar en Informática y disfrutar con ella hasta la fecha. Y lo que el cuerpo aguante. Y además, le gusta la música...
 

{ 21 } Comentarios

  1. Gravatar ubersoldat | 13/04/2009 at 03:40 | Permalink

    Cuando dices que las BBDD eran navegacionales, te refieres a que funcionaban como XML hoy en día? Pobres, luego hablan de la “edad de oro” :)

  2. Gravatar Jose Suárez de Lezo | 14/04/2009 at 10:49 | Permalink

    Yo si que conozco la historia de Blas de Lezo, es antepasado mío. De todas formas tienes razón aquí tendemos a despreciar la historia de España y ha ensalzar la historia extranjera, tal vez el habernos criado con Westerns influya bastante. Yo se que el PCL se desarrollo por IBM España, no sabia que fuera en Barcelona, también te puedo contar que en los primeros años del AS/400 se realizo una utilidad para gestionar las distintas colas de trabajo aquí en Valencia y en varios agentes IBM la vendían bajo bandera Holandesa.

    Por cierto otro interesantísimo artículo de la historia de la informática.

  3. Gravatar Jimmy Jazz | 14/04/2009 at 01:29 | Permalink

    Que alegría volver de semana santa, y al menos encontrarte otro estupendop artículo del bueno de Mac! Y cuanto mas tienen de batallita personal, más me gustan jejej!

    ;)

  4. Gravatar Macluskey | 14/04/2009 at 02:05 | Permalink

    @Jimmy Jazz: TODAS las entradas tienen tintes de batallitas personales, aunque no lo parezcan. Estoy contando lo que yo sé, lo que viví, lo que leí, lo que me pareció en cada momento. Vale que para poner años y detalles concretos haya que acudir a documentarse, pero no estoy escribiendo nada que no supiera de primera mano… Ya sabes: El que quiera saber la Historia oficial, que vaya a la wikipedia, que está muy bien…:D

    @José: ¡Vaya! Un descendiente de MedioHombre… qué tipo! Desde que conocí su historia me fascinó, y me fascina más aún que haya tan poquísima gente que sepa quién fue… como mucho te dicen: “Blas de Lezo? Eso es una calle, verdad?” Y sí, fue en Barcelona: conocí yo, años después, a alguno de los intervinientes en aquél proyecto, casi todos españoles… Y se desarrollaron muchas más aplicaciones y sistemas, como el que comentas en Valencia (que no conocía, por cierto: ya sabes que el AS/400 no es lo mío…). Por cierto, José, tú que sabes de AS/400 y su RPG… ¿Qué tal un artículo para desasnarnos a los que ignoramos todo sobre esa excelente máquina? Piénsatelo… la Comunidad te lo agradecerá. (Aquí un emoticono de sonrisa pillina y cómplice a la vez que confiado y gracioso..)

    @ubersoldat: Pues… sí, más o menos. Pensé que lo había explicado (má o menos) en el artículo, pero veo que no es así… lo revisaré.

    Gracias a todos por comentar.

  5. Gravatar Jose Suárez de Lezo | 14/04/2009 at 04:31 | Permalink

    Pues te preparo el articulo sobre el As/400 y el RPG, aunque no creo que llegue a ser tan ameno como los tuyos. Te comento que Blas de Lezo estuvo a las ordenes de Felipe V participo en el sitio a Barcelona en 1.714 hecho sangriento que le habra hecho daño como figura de la historia de España. Bueno a lo tecnico, te preparo el articulo y en unos dias te lo paso.

  6. Gravatar Macluskey | 14/04/2009 at 05:39 | Permalink

    @José: Me parece muy bien. Te contesto por email para que me tengas localizado…

    Saludos

  7. Gravatar Jimmy Jazz | 15/04/2009 at 10:05 | Permalink

    Por cierto, buenísimo el texto de Jesús Martín Tardío sobre la RETD.

  8. Gravatar joel | 15/04/2009 at 12:06 | Permalink

    Ey! Yo trabajo con una IDS, sólo que es una Informix Dinamic Server (jejeje).

    He echado en falta, algún tipo de explicación de por qué estos tipos de bases de datos de red o jerárquicas son mucho más eficientes (aunque también mucho más difíciles de programar y mantener) que las relacionales para tratar con volúmenes de datos enormes. Has explicado la problemática y no las ventajas (hay que ser más positivo ;-) ), pero entiendo que lo haces porque te sirve como introducción a las BBDD relacionales.

    Supongo que ya saldrá algún apéndice/anexo técnico en la serie para explicar cosas así, y si no, aquí queda mi petición.

  9. Gravatar Macluskey | 15/04/2009 at 02:34 | Permalink

    @joel: Bueno, quizá quedará más claro en la entrada de las Bases de Datos Relacionales, pero básicamente se trata:

    Del lado Relacional: Facilidad de diseño y de programación, más despreocupación total por cómo se las apaña el Optimizador para resolver la query, a cambio de un peor rendimiento y mayor necesidad de espacio en disco;

    contra:

    Del lado jerárquico: Rapidez y eficacia en los accesos a los Datos, y menor consumo en disco, a cambio de mayor dificultad de diseño y programación, y de nula compatibilidad entre ellas.

    And the winner is… ¡La vagancia!; además, como las máquinas cada vez son más rápidas, tienen más memoria, más disco… pues está claro quién es el que domina el cotarro. Y sin embargo, cuando se necesita de verdad una rapidez endiablada para acceder a Teras de información (léase Google, por ejemplo), no hay relacional que valga: índices invertidos!

    En cualquier caso, si te estás peleando con un Informix Dynamic Server (de IBM, por cierto) sabrás que cuando una query no va bien y hay que conseguir que vaya bien (o sea, optimizar al optimizador)… que no te pase ná. Una locura.

    Pones índices, quitas índices, cambias la estructura de la query… todo por puritito ensayo/error en muchos casos: “Cambia la join por una subselect, a ver qué tal va ahora…”, y si no va, “Quita el having y pon un group by, a ver qué pasa…” y así todo.

    Tengo, o no tengo razón?

    Un saludo, compañero!

  10. Gravatar joel | 15/04/2009 at 08:09 | Permalink

    En cualquier caso, si te estás peleando con un Informix Dynamic Server (de IBM, por cierto) sabrás que cuando una query no va bien y hay que conseguir que vaya bien (o sea, optimizar al optimizador)… que no te pase ná. Una locura.

    Pones índices, quitas índices, cambias la estructura de la query… todo por puritito ensayo/error en muchos casos: “Cambia la join por una subselect, a ver qué tal va ahora…”, y si no va, “Quita el having y pon un group by, a ver qué pasa…” y así todo.

    Tengo, o no tengo razón?

    :-)

    Tanto como locura…? Dejémoslo en “entretenido”

    Poco a poco se le pilla el truco: usar unos índices en vez de otros, sólo buscar valores indexados (aunque sea de forma indirecta), usar subselects en vez de joins cuando ya tienes demasiados o sólo es para “pequeñeces” (como muy bien has dicho), usar tablas temporales y crearles sus propios índices, y tener en cuenta que al ser “dynamic” la velocidad de una consulta varía dependiendo de si los datos ya están en memoria (es decir, que la segunda vez que se hace una consulta no tarda nada).

    El que programó la aplicación que uso/”mantengo” lo hizo hace más de 10 años y todo lo resuelve con cursores en vez de joins, y debe de ser por la optimización del motor que ahora tales consultas van bastante más lentas que una query bien preparada.

  11. Gravatar Lucas | 15/04/2009 at 11:23 | Permalink

    Es cierto que no precisamente los personajes históricos más interesantes son los más conocidos, y que a veces se exalta demasiado a quienes no se lo merecen. Al fin y al cabo, el único ser que tiene la capacidad de modificar el pasado es el historiador.

    Cambiando de tema, me asusté por un instante cuando dijiste “Un DBMS debía, en primer lugar, asegurar…”, ya que esa sigla en otro orden significa otra cosa.

    Un saludo, egregio amigo.

  12. Gravatar Macluskey | 16/04/2009 at 09:31 | Permalink

    @joel: Si lo calificas de “entretenido” en lugar de “locura”, es que llevas tanto tiempo peleándote con el IDS que sabes más que el que lo programó hace la tira…

    Y lo de escribir las aplicaciones con cursores, evitando joins y subselects, y restringiendo muchas posibilidades es una herencia de cómo funcionaban (mejor: NO funcionaban) las primeras RDBMS’s… como veremos en el próximo episodio, que habla precisamente de los comienzos de las BD Relacionales).

    @Lucas: Lo siento, amigo: mis limitadísimos conocimientos me impiden saber qué es un DBMS más allá de un DataBase Management System… pero es que le he preguntado al google, a la wikipedia y a un par de diccionarios… ¡y tampoco saben qué es un DBMS fuera de un Gestor de Base de Datos!.

    ¿Desastre Bestial por Movimiento Sísmico?

    ¿Dinámica Basal Mentirosa y Sospechosa?

    ¿Dictador Bielorruso Machista y Sádico?

    … Espero me saques de mi ignorancia, GGET (Gran Gurú del Espacio-Tiempo)…

    Saludos a todos

  13. Gravatar Nk0 | 16/04/2009 at 04:32 | Permalink

    La verdad es que esta serie de artículos están muy bien, sobre todo para la gente como yo, nuevos informáticos que desean saber más de aquellos años en los que todo era completamente diferente.

    Mis felicitaciones al autor, tanto por su forma amena de contar las cosas como por la documentación que conlleva el hacer este tipo de entradas.

    Pero ante todo, gracias por culturizar a las nuevas generaciones, por hacernos ver que ahora la informática aunque sigue siendo compleja en muchos sentidos, lo es bastante menos que antes en otros.

    Saludos

  14. Gravatar Dadá | 17/04/2009 at 08:59 | Permalink

    Es que no se trata de las letras en sí, si no de el orden en el que aparecen. No es lo mismo DBMS que lo otro… :)

    Lo que no cambia es la calidad de las entradas. Mis felicitaciones.

  15. Gravatar badaman | 17/04/2009 at 10:03 | Permalink

    El enlace sobre la RETD, -al igual que el artículo, por supuesto- ha sido muy interesante. Nos muestra otras formas de uso de aquellos ordenadores de los 60-70. Hace unos años encontré un documento que muestra como en España también éramos pioneros en otras áreas relacionadas con la computación. Se trata de “Los orígenes del arte cibernético en España”, un documento de Enrique Castaños Alés que se encuentra en la Biblioteca Virtual Miguel de Cervantes, que habla sobre el uso artístico que se dió en el Centro de Cálculo de la Universidad de Madrid a un IBM 7090 y un IBM 1401 en el marco del seminario de generación automática de formas plásticas.

    http://www.cervantesvirtual.com/FichaObra.html?Ref=3162

  16. Gravatar Macluskey | 17/04/2009 at 02:01 | Permalink

    @Dadá: Pues… sigue sin ocurrírseme. MBDS? DMBS? BSMD? ¿?

    Lo siento, mis neuronas no dan para más. Es lo que hay. Pero lo seguiré intentando….

    @Badaman: Un enlace muy interesante (que yo desconocía, por cierto). Gracias por compartirlo.

    Saludos a todos y gracias por vuestros comentarios.

  17. Gravatar Pedro | 17/04/2009 at 03:11 | Permalink

    Mac, http://es.wikipedia.org/wiki/BDSM

  18. Gravatar Macluskey | 17/04/2009 at 03:40 | Permalink

    AAAAAAAAAAAAAAAHHHHHHhhhhhhhh!

    Con razón no me enteraba de nada… se ve que soy un viejo inculto y tradicionalista, que no se entera de las nuevas tendencias…

    En fin, qué se le va a hacer. Lo que no tié remedio, no lo tié.

    Gracias por desasnarme, Pedro.

  19. Gravatar DirectorioInformatic | 31/01/2010 at 10:03 | Permalink

    Creo que las bases de datos son muy prácticas para almacenar datos, pero por otro lado las encuentro un coñazo,demasiado complicadas ;)

  20. Gravatar Venger | 19/01/2012 at 06:42 | Permalink

    Lo que me he podido reir con lo del BDSM, ja ja ja. Anécdota total.

    Mi experiencia con las bases de datos. Yo me creé una en access para mi empresita, para llevar la facturación, pero luego he migrado al Excel porque lo veía muchísimo más fácil a la hora de hacer modificacines. Y sí, en excel se puede simular perfectamente bases de datos relacionales. Desde entonces fui más feliz. Me debió pasar lo que dice Mac, “volver a acercar la tecnología al negocio”

  21. Gravatar Macluskey | 19/01/2012 at 07:16 | Permalink

    Qué cosas… “acercar la tecnología al negocio”… Eso decíamos hace quince o veinte años, o más, cuando los ordenadores eran unas cosas raras programadas por tíos (y tías) todavía más raros…

    Eso ha pasado a la historia.

    Ahora La Tecnología ES el negocio. O lo que es lo mismo: no hay negocio sin tecnología.

    Un ejemplo: Ya nadie compra ni vende nada en Bolsa: lo hacen unas máquinas perversas que nos traen a mal traer a todos. En la mayoría de casos, las decisiones de compra o venta las toman ellas solitas… Vete tú a decir al responsable de Riesgos de Mercado que vas a “acercar la tecnología al negocio” y verás lo que te dice…

    Gracias por tu comentario.

{ 4 } Trackbacks

  1. Gravatar meneame.net | 13/04/2009 at 02:54 | Permalink

    Historia de un viejo informático: El camino hacia las bases de datos relacionales…

    Nuevo volumen de las historias de nuestro amigo "el viejo informático". Esta vez relatando la llegada al mercado de las bases de datos relacionales….

  2. [...] la primera red de conmutación de paquetes mundial fue española Técnico Leyendo hoy un artículo de la serie de El Cedazo Historias de un viejo informático de Macluskey me entero de algo que es [...]

  3. [...] la entrada anterior vimos los comienzos de las Bases de Datos (jerárquicas o en red, siguiendo en más o en menos el [...]

  4. [...] Macluskey en una de sus batallitas del abuelo [...]

Escribe un comentario

Tu dirección de correo no es mostrada. Los campos requeridos están marcados *

Al escribir un comentario aquí nos otorgas el permiso irrevocable de reproducir tus palabras y tu nombre/sitio web como atribución.