BD muy grandes ¿Qué criterio usar?

[[coso]]

bueno, la polemica esta servida:

se guarda el id y el raw data, si tienes una imagen jpeg de 25 gb comprimida y la guardas tipo raw (o sea el estilo BLOB habitual, a no ser que quieras trabajar un poco) probablemente te crecera a unos 125 gb. Creo que es mejor dejarlo en formato jpg, no?

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.

si bien sql esta muy bien para buscar texto en bases de datos, lo que tardara muchisimo es cargar y descargar todos estos datos a memoria para luego buscar en ellos. quiza seria mejor buscar directamente a disco no? 50 gb de texto el so pasara a memoria cache y, al final, sera lo mismo que buscar desde disco directamente.

- Unir la información de varias tablas (muy posiblemente distintos archivos) haciendo la búsqueda más compacta y eficiente.

50gb + 50gb = 100gb...no creo que la busqueda fuese mas compacta y eficiente.

- filtros muy especializados.

si miras lo que le propuse (grep.exe) veras que no es mas que un antecedente de lo que ahora se usa para filtros y busquedas.

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?

el bloc de notas no te carga 1gb de datos

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

claro que tendras volumen, lo que no tendras son entradas para la bd. En tu caso asi haria un sistema de carpetas y en ellas poner toda la información necesaria, y en la base de datos tansolo poner las referencias a estas carpetas y a los archivos. Aunque, si se que van a ser pocas las entradas, puedo saltarme directamente el paso de la base de datos y que la aplicacion mirara, por ejemplo, el numero de carpetas que existe y sacar la información necesaria de ellas directamente : en vez de un dbgrid, usaria un ttreeview, para que lo entiendas.