Barrapunto

Son 0,17 Petas/año, no 1,7.

Ya, es que con un par de cervezas los ceros se ven doble y claro, te pones a contarlos y noacabas :P

Como ya te han dicho, apestas a trauma infantil y no mereces escribir aquí. Sin embargo, voy a responder a este comentario no por tí, sino por los posibles lectores de este hilo.

---------------------------------------------

1. Dimensionamiento de BBDD

En cualquier entorno medianamente bien organizado, cuando vas a poner en producción una nueva aplicación que incluye una base de datos, los responsables de BBDD del departamento de sistemas correspondiente te requieren que les envíes un documento con los tamaños iniciales de las tablas y el crecimiento estimado de las mismas. A partir de este documento los administradores deciden cuantos tablespaces crear y de qué tamaño crearlos. En Oracle, tablespaces. En otros SGBD, pues se manejan otras estructuras. En cualquier caso, el procedimiento siempre es el mismo: Le das una estimación del tamaño inicial y del crecimiento esperado de la BBDD a los administradores y ellos deciden la estructura física de tu base de datos.
Una configuración habitual para el tipo de aplicaciones en las que he trabajado está compuesta por seis tablespaces. Tres para las tablas "pequeñas", "medianas" y "grandes" y tres para los índices "pequeños", "medianos" y grandes".

2. Procesos de negocio "en papel"

Muchas empresas tienen procesos de negocio críticos basados en papel. Por ejemplo, casi todo lo relacionado con medios de pago y en especial las tarjetas de débito/crédito generan muchísimo papel. Por ley, toda esa información tiene que almacenarse durante periodos de tiempo muy largos. Además, es información vital para la compañía. Si haces una compra con tarjeta, reclamas y no encuentran el recibo, no tienes obligación de pagar.
Las empresas que proveen servicios de consumo masivo, como las eléctricas o las telecos también tienen ciertos procesos de negocio basados en papel. Cuando alguien se compra un teléfono móvil postpago (de contrato), usualmente rellena un contrato en papel y lo firma.
Hay muchísimos ejemplos de procesos de negocio basados en papel. Cuando firmas un contrato de trabajo, cuando el bar de la esquina firma un contrato con Coca-cola, cuando la tienda de la otra esquina firma con Panrico para que le lleven donuts cada mañana, etc.

3. Gestión documental

Todos estos documentos en papel se tratan, en general, en tres etapas: se escanean, se pasan por un reconocedor de caracteres y/o un operador y se almacenan para su posterior consulta. El volumen de datos generado es inmenso, habitualmente del orden de Petabytes/año. Cualquier SGBD tradicional es insuficiente para manejar este volumen de datos. Se puede optar entre diversos sistemas diseñados específicamente para esta tarea, como Filenet [filenet.com], Documentum [documentum-es.com], Ixos [documentum-es.com], etc.
El almacenamiento se lleva a cabo en robots de almacenamiento masivo, ya sean de cinta o basados en soportes ópticos. Yo sólo he trabajado con Centera [emc.com] e IBM [ibm.com].

Una situación especialmente interesante se da cuando una empresa tenía un gestor documental, se acaba de comprar otro y quiere migrar los datos.

3. Gestión documental en HIS

HIS son las siglas en inglés de Sistema de Información para Hospitales (traducido libremente).
Los sistemas de gestión documental también se integran en los HIS. Imagina que estás de vacaciones en Cádiz y te rompes un brazo. Imagina que a los diez minutos de hacerte una radiografía en el hospital de Cádiz la pudiera ver tu médico de cabecera en Orense.

---------------------------------------------

Ahora sí me dirijo a ti, pobrecito hablador malhumorado, para hacerte una pregunta. ¿Crees que se pueden almacenar toda esta información en un Oracle/posgre/MySQL/otro? La pregunta es más bien retórica; no m