Barrapunto

Meter las imagenes en la base de datos nos aporta otra serie de ventajas, por ejemplo, si se conecta un cliente remoto via inet, la misma aplicación recibirá las imagenes como si fuese local, entre otras cosas.

No se me habia ocurrido esa posibilidad, si se quiere acceder a la informacion desde otro host diferente al de la base de datos o desde una aplicacion (lo mas normal por cierto) entonces si que seria mas que logico meter los ficheros en la base de datos. Aunque en este caso dice que lo quiere para una pagina web y podrian almacenarse tambien en el sistema de ficheros del servidor de la pagina.. pero creo que tienes razon, si es una base de datos importante que es susceptible de ser modificada / adaptada a nuevas necesidades en un futuro si es logico hacerlo asi.

el tamaño de la base debe ser enorme, solo de imaginarmelo ,pienso en servidores y sistema de almacenamiento muy muy grandes, solo por curiosidad una radiografica pasada a imagen ¿cuanto mide?.

"El volumen es mas o menos importante, unas 20000 mensuales y bueno, me parece una chapuza informática meter semejante número de ficheros en un sistema de archivos"

¿Y por qué te parece una "chapuza informática"? Los sistemas de ficheros están pensados para... almacenar ficheros. Aparte de una mayor sobrecarga operacional, ¿qué te ofrece el motor de la base de datos? ¿Vas a consultar información jerarquizada de *dentro* del contenido de los ficheros acaso? ¿Vas a tener alguna posibilidad de ordenación a parte del propio nombre que le puedas dar al fichero y/o atributos definidos *externamente* al propio fichero? Los sistemas de fichero están optimizados para recuperar elementos por nombre y para bombear datos a la máxima velocidad al sistema operativo que se los solicita, a poco cuidado que tengas, el acceso al sistema de archivos va a ser siempre considerablemente más rápido (y más flexible, y más extensible) que extraer un blob desde el RDBM, y casi en cualquier caso no va a poder ser, casi ni queriendo, más lento.

Lo que más gracia me hace es que más de cuatro -que obviamente no distinguirían su culo de su polla, ni marcándosela con un rotulador- proponen el caso más disparatado: meter las imágenes en la base de datos si son muchas y grandes, y dejarlas en el sistema de ficheros si son pocas y pequeñas cuando, en fin, si hay una postura *algo* defendible, es justamente la contraria: utilizar la base de datos si el volumen es pequeño, ya que la "compactación" de los datos (todo en el mismo sitio) y del desarrollo (a todo se accede de la misma manera) puede -quizá- compensar la barbaridad que estás haciendo (del mismo modo que si te apetece una cerveza, te metes al primer bar que veas aunque sepas que va a ser más cara, pero cuando te quieres comprar un coche, te tragas un montón de concesionarios, lo que es un coñazo a corto plazo, pero compensa grandemente).

"Meter las imagenes en la base de datos nos aporta otra serie de ventajas, por ejemplo, si se conecta un cliente remoto via inet, la misma aplicación recibirá las imagenes como si fuese local, entre otras cosas"

Ein? Ya lo he dicho en otro mensaje: ver cuál es el único caso en el que es preferible la inclusión de datos binarios en la base de datos. Te acabas de retratar, chato.

"de todas maneras si hay que hacer un backup de las imágenes, también ocuparán lo suyo aunque sean archivos."

Sí, pero podrás hacerlo en cualquier momento, con contención nula por lo que respecta a la aplicación que accede a ellas, en un sistema que podrás optimizar específicamente para la tarea de la que se va a ocupar (piensa, por poner lo primero que se me ocurre, que no lo único, en XFS...), y las imágenes serán accesibles *por sí mismas* incluso en caso de caída catastrófica de la base de datos, o para operaciones que ni siquiera se habían pensado en la aplicación original, con posibilidades muy sencillas de "split" vertical de los datos (puedes poner, para cada historia, los datos más antiguos en almacenamiento "tibio" con gran facilidad...).

"Pero como siempre, para gustos, los colores"

No es cuestión de gustos, sino de saber hacer las cosas.

... para que preguntas. Te han dado bastantes razones de por qué separar los ficheros y la BB.DD, con las que estoy de acuerdo(Oracle aparte, probablemente tenga su manera de hacerlo dentro de sí mismo, pero es que casi es un S.O. de por sí). Yo te voy a dar el punto de vista de sistemas, por si te valen de algo, ya que tenemos una aplicación bastante parecida.

Si vas a generar 170GB de datos al año, tienes que tener en cuenta el coste y función de los discos. Los requerimientos para una BB.DD. con cierta carga son distintos que para un FS donde vas a escribir casi secuencialmente y en el que no vas a borrar prácticamente nada (baja fragmentación). En el primer caso, raid 5 preferiblemente por hardware con discos SCSI no muy grandes(¿36GB?) sería una buena elección. Para el segundo caso, discos grandes SATA/IDE con RAID 1 por Soft sería suficiente (preferiblemente en una NAS que exporte por NFS, las hay bastante baratas y además descargas de CPU a la máquina de la BB.DD).

Meterlo todo en la BB.DD. ralentizará muchísimo las inserciones y lecturas, y hará que tengas discos "caros" desaprovechados y fragmentados. Insisto que una NAS barata puede ser una buena inversión, por 4.000eur tienes asegurada la escalabilidad, además siempre puedes usarla para otros proyectos.Aparte es más difícil corromper un FS que una BB.DD.

Evidentemente, una jerarquía de directorios lógica es necesaria.

Dicho lo dicho, tu verás. Es tu proyecto y lo gestionas como quieres.