BD muy grandes ¿Qué criterio usar?

[[Delphius]]

Hola PaFernan99,
Estoy con coso, no creo que sea tan viable empezar un sistema de cero. A menos que sea demasiado a la medida, y tengas los recursos, el presupuesto y el tiempo necesario me parece que es mejor buscar algo ya hecho.
¿Es para ti el sistema? ¿Para un cliente en particular? O por el contrario... ¿Un desarrollo genérico y con posibilidad de licenciamiento a muchas empresas?

Aqui en Salta, PLUMADA ofrece un servicio de gestión y resguardo de información tanto física como digital. ¿No hay una empresa así por allí?
Eso si, los servicios de PLUMADA no son tan baratitos que digamos.

Saludos,

[[coso]]

Estoy con coso, no creo que sea tan viable empezar un sistema de cero

no,no, si yo decia lo contrario

[[Delphius]]

Empezado por coso

no,no, si yo decia lo contrario

Juraría haber leído un "Pero" entre "...tu propio sistema," y "dejando las imágenes..."

No más digo que tal vez lo mejor, como una opción o alternativa a contemplar es emplear algo ya hecho. En este caso, yo di el ejemplo de PLUMADA, que ofrece el servicio de resguardo y gestión de documentos físicos y digitales (que no es lo único que hace).

En fin, ya nos dirá PaFernan99 que es lo que se está buscando.

Saludos,

[[coso]]

No no, mi idea era que creara un sistema de carpetas, correspondiendo cada directorio a una entrada en la base de datos. Si pone imagenes de 10Gb y cosas por el estilo (por otra parte, que lo veo muy exagerado) lo mejor seria trabajar con el formato nativo de las imagenes, ya que tendran su propio tipo de compresion, etc...si se pone raw data en la base de datos, quiza cada entrada te ocupa ...no se...230 Gb. Hacer un browse a una base de datos asi seria lentisimo. Te recomiendo otra vez eso mismo: usar en tu bd tansolo las referencias a los archivos, y crear un sistema fijo de directorios,etc...cargando y haciendo previews segun necesites. De todas maneras, si se opta por un alojamiento externo, la velocidad de subida y bajada de red tendra que ser mas que aceptable para que tu programa no se vaya estancando cada segundo.

[[Delphius]]

Empezado por coso

No no, mi idea era que creara un sistema de carpetas, correspondiendo cada directorio a una entrada en la base de datos. Si pone imagenes de 10Gb y cosas por el estilo (por otra parte, que lo veo muy exagerado) lo mejor seria trabajar con el formato nativo de las imagenes, ya que tendran su propio tipo de compresion, etc...si se pone raw data en la base de datos, quiza cada entrada te ocupa ...no se...230 Gb. Hacer un browse a una base de datos asi seria lentisimo. Te recomiendo otra vez eso mismo: usar en tu bd tansolo las referencias a los archivos, y crear un sistema fijo de directorios,etc...cargando y haciendo previews segun necesites. De todas maneras, si se opta por un alojamiento externo, la velocidad de subida y bajada de red tendra que ser mas que aceptable para que tu programa no se vaya estancando cada segundo.

Ha, ahora entiendo.
En este punto si estamos de acuerdo. No es viable estar guardando en la base de datos imágenes o documentos que pesen tanto... En este caso creo que lo mejor es tener la ruta guardada, y en un/os directorio/s específico las imágenes y documentos.

Ahora que leo bien lo que nos aportó PaFernan99, no se si los servicios de PLUMADA sean tan orientados a la web

Saludos,

[PaFernan99]

Hola coso y Delphius!
Gracias por vuestras opiniones.
Con respecto a lo que decías Delphius, desarrollar el sistema no solo es viable, sino imprescindible. Estoy trabajando en un archivo documental muy importante en cuando a volumen (el más importante de sudamérica, está aca en Argentina ).
Tu propuesta es valedera, coso, ya que actualmente tienen un sistema funcionando así, pero que fue desarrollado a principios del 2000, y les ha quedado muy chico (8 de las 9 colecciones quedaron afuera).
Utilizan un motor SQL server.
¿Tu sugerencia es que haga las búsquedas en los archivos de texto directamente, o utilice la BD para almacenar el texto, realizar las búsquedas sobre este y recuperar las imágenes por medio de la referencia?
Olvidemonos ya de cargar las imágenes en la BD, eso queda descartado.

Gracias por la ayuda!

[[coso]]

Bueno, quiza seria mejor usar la bd unicamente para referenciar los archivos (aunque de la manera que hablas, con solo 9 "colecciones", tampoco haria mucha falta usar una base de datos). En cuanto a buscar texto dentro de cada coleccion, etc, usaria mas bien codigo propio, o bien llamando a programas externos (por ejemplo, crear un grep.exe o usar alguno existente, pues es algo antiguo y los hay de muy muy buenos) que escanearan los archivos, recogiendo su resultado y que lo mostrase tu programa

[mamcx]

Y que contiene cada coleccion? Se les hace OCR a las imagenes? Que es lo que se busca?

[[duilioisola]]

A mi me falta información para poder decidir sobre este tema:
- Cada colección tiene 50GB de qué? (qué tipo de imagen, texto, video, audio, etc.)

- Esa colección es un solo archivo o está separado en miles de archivos (imágenes, textos, etc.)

Si son miles de archivos, podrás utilizar la base de datos para buscarlos, si son solo 9 archivos, no vale la pena.

Cuando quieras seleccionar algo que haz encontrado, y quieras traértelo,
- ¿Te traerás 50GB?
- ¿Te traerás 1 o 2 GB de texto?
- ¿Te traerás pocos megas de una imagen o un archivo?
- ¿Te traerás solo el nombre y la descripción del archivo?

Una base de datos, con un campo blob que tenga que traerse mas de 100MB supongo que será muy lento.

También te puedes hacer un diccionario en una base de datos que te dijera que palabra de más de 4 letras está en qué archivo y así poder hacer búsquedas.

Todo esto, también hay que pensarlo en cuanto a velocidad de subida/bajada.
- Si es a travez de internet y tienes que bajar una colección serán 50GB.
- Si es a travez de internet y tienes que bajar un texto serán 1-2GB.
- Si es a travez de internet y tienes que bajar parte de un texto.

[[Lepe]]

Ejem, un punto de vista diferente: Los campos Blob no se guardan como un campo más del registro. En realidad, en el registro se guarda un IDBlob, el blob físico por tanto, quedará en otra parte del archivo. Por ello la "eficiencia" no tiene nada que ver con la longitud del campo Blob.

Incrustar imágenes en la BBDD está justificado para no lidiar con rutas que algún avispado, pueda cambiar el nombre del archivo/carpeta.

Dejar los archivos fuera está justificado para no lidiar con un sólo archivo de 500 GB, por ejemplo.

Para más información consultar el buscador, ya hay discusiones suficientes como para empezar otra, además veo que PaFernan99 ya tomó una decisión al respecto.

Volviendo al tema: yo opino de forma distinta a coso. Yo Incluiría todos los textos dentro de la BBDD; fuera de ella sólo los archivos de gran tamaño. Esto te permite:
- hacer búsquedas flexibles sin necesidad de herramientas externas.
- Unir la información de varias tablas (muy posiblemente distintos archivos) haciendo la búsqueda más compacta y eficiente.
- filtros muy especializados.
- etc.

En cuanto al texto no lo tengo claro, dices que la imagen escaneada es de 1 GB pero, ¿tienes posibilidad de pasarlo al bloc de notas y guardarlo para saber el tamaño real del texto?

Si son grandes descripciones o artículos de revista, te sería de gran utilidad guardar palabras de referencia para las búsquedas (algo así como los tags de las páginas web o Youtube), en lugar de buscar en el texto del artículo, buscas en esas referencias. Sin duda acortaría las búsquedas muchísimo.

OFFTOPIC: coso, yo sólo tengo 9 propiedades... no es mucho, algunas son: BP, CARREFOUR, EL CORTE INGLÉS, GM, SPAINAIR... ¿tendré volumen de información que guardar .

Saludos