database - ruta - mostrar imagen desde base de datos php

Para hacer o no hacer: almacenar imágenes en una base de datos (14)

Esta pregunta ya tiene una respuesta aquí:

Almacenar imágenes en DB - ¿Sí o No? 56 respuestas

En el contexto de una aplicación web, mi antiguo jefe siempre decía poner una referencia a una imagen en la base de datos, no a la imagen en sí misma. Tiendo a estar de acuerdo en que almacenar una url frente a la imagen en el DB es una buena idea, pero donde trabajo ahora, almacenamos muchas imágenes en la base de datos.

¿La única razón por la que puedo pensar es que es más seguro? ¿No quieres que alguien tenga un enlace directo a una url? Pero si ese es el caso, siempre puede hacer que el sitio web / el servidor maneje las imágenes, como los manejadores en asp.net, de modo que un usuario necesite autenticarse para ver la imagen. También estoy pensando que el rendimiento se vería afectado al sacar las imágenes de la base de datos. ¿Alguna otra razón por la que podría ser una buena / no tan buena idea almacenar imágenes en una base de datos?

Duplicado exacto: Imágenes del usuario: ¿Almacenamiento de la base de datos o del sistema de archivos?
Duplicado exacto: almacenamiento de imágenes en la base de datos: ¿sí o no?
Duplicado exacto: ¿Debo guardar mis imágenes en la base de datos o en las carpetas?
Duplicado exacto: ¿almacenaría datos binarios en una base de datos o carpetas?
Duplicado exacto: ¿ Almacenar imágenes como archivos o la base de datos para una aplicación web?
Duplicado exacto: almacenando una pequeña cantidad de imágenes: blob o fs?
Exact Duplicate: ¿ almacenar imagen en un sistema de archivos o base de datos?

Almacenaba imágenes en una base de datos para una aplicación de demostración. La razón por la que lo hice fue por seguridad: borrar un registro que no debería tener no era un gran problema, ¡pero borrar un archivo que no debería tener podría haber sido un problema!

Si el rendimiento se convirtió en un problema, habría investigado si la eliminación de archivos no autorizados era una posibilidad real o no.

Entiendo que la mayoría de los profesionales de bases de datos le cruzarán los dedos si le almacena imágenes en la base de datos (o incluso las menciona). Sí, definitivamente hay implicaciones de rendimiento y almacenamiento cuando se utiliza la base de datos como repositorio de grandes bloques de datos binarios de cualquier tipo (las imágenes tienden a ser los bits de datos más comunes que no se pueden normalizar). Sin embargo, sin duda hay circunstancias en las que el almacenamiento de las imágenes en la base de datos no solo es admisible sino aconsejable .

Por ejemplo, en mi trabajo anterior teníamos una aplicación en la que los usuarios adjuntaban imágenes a varios puntos diferentes de un informe que estaban escribiendo, y esas imágenes tenían que imprimirse cuando se realizaba. Estos informes se movieron a través de la replicación de SQL Server, y habría introducido un ENORME dolor de cabeza para tratar de administrar estas imágenes y rutas de archivos a través de múltiples sistemas y servidores con cualquier tipo de fiabilidad. Almacenarlos en la base de datos nos dio todo eso "de forma gratuita", y la herramienta de informes no tuvo que ir al sistema de archivos para recuperar la imagen.

Esto realmente parece un problema de KISS (lo mantiene simple y estúpido). Los sistemas de archivos están diseñados para manejar fácilmente archivos de imágenes, pero no es fácil de hacer en una base de datos y es fácil estropear los datos. ¿Por qué tomar un golpe de rendimiento y toda la dificultad en el sql y el renderizado cuando solo puede preocuparse por la seguridad del archivo? También puede manejar sistemas mixtos con NFS o CIFS. Los sistemas de archivos son tecnologías maduras. Mucho más simple, más robusto.

La mayoría de las bases de datos SQL por supuesto no están diseñadas para servir imágenes, pero hay una cierta cantidad de conveniencia asociada con tenerlas en la base de datos.

Por ejemplo, si ya tiene una base de datos ejecutándose y ha configurado la replicación. Inmediatamente tiene un almacén de imágenes HA en lugar de tratar de trabajar con una replicación de sistema de archivos basada en rsync o nfs. Además, tener un montón de procesos web (o diseñar algún servicio nuevo) para escribir archivos en el disco aumenta un poco su complejidad. Realmente son solo partes más móviles.

Por lo menos, recomendaría mantener datos ''meta'' sobre la imagen (como cualquier permiso, quién es el propietario, etc.) y los datos reales separados en diferentes tablas, por lo que será bastante fácil cambiar a un almacén de datos diferente la línea. Eso, junto con algún tipo de almacenamiento en caché o CDN, debería ofrecerle un rendimiento bastante bueno hasta cierto punto, por lo que supongo que depende de qué tan escalable debe ser esta aplicación y cómo se equilibra eso con facilidad de implementación.

La solución más simple / más eficiente / más escalable es almacenar sus imágenes en el sistema de archivos. Si la seguridad es una preocupación, colóquelos en una ubicación a la que no pueda acceder el servidor web y escriba un script que maneje la seguridad y sirva los archivos.

Suponiendo que su servidor web / de aplicaciones y servidor de bases de datos son máquinas diferentes, tomará algunas visitas poniendo imágenes en la base de datos: (1) latencia de red entre las dos máquinas, (2) sobrecarga de conexión DB, (3) consumiendo una base de datos adicional conexión para cada imagen servida. Me preocuparía más el último punto: si su sitio sirve muchas imágenes, sus servidores web consumirán muchas conexiones de BD y podrían agotar sus grupos de conexiones.

Mi consejo general sería que no te limites a un enfoque u otro, ve con la técnica que se adapte a la situación. Los sistemas de archivos son muy buenos para almacenar archivos, y las bases de datos son muy buenas para proporcionar trozos de datos del tamaño de un bocado cuando se solicitan. Por otro lado, uno de los productos de mi compañía tiene el requisito de almacenar todo el estado de la aplicación en la base de datos, lo que significa que los archivos adjuntos también entran allí. Con nuestro servidor de bases de datos (SQL Server 2005) todavía tengo que enfrentar problemas de rendimiento observables incluso con grandes clientes y bases de datos.

El SQL 2008 de Microsoft le ofrece lo mejor de ambos mundos con la característica FileStream; podría valer la pena visitarlo. http://technet.microsoft.com/en-us/library/bb933993.aspx

No tiene que almacenar la URL (si siente que no es seguro). Solo puede almacenar una identificación única que haga referencia a la imagen en otro lugar.

El almacenamiento de la base de datos tiende a ser más costoso y costoso de mantener que un sistema de archivos; por lo tanto, no almacenaría MUCHAS imágenes en una base de datos.

Pros de poner imágenes en una base de datos.

Actas. Cuando guarde el blob, puede hacerlo como cualquier otro dato de base de datos. Eso significa que puede comprometer el blob junto con cualquiera de los metadatos asociados y tener la seguridad de que los dos están sincronizados. Si te quedas sin espacio en el disco? Sin compromiso El archivo no se cargó por completo? Sin compromiso Tonto error de la aplicación? Sin compromiso Si mantener las imágenes y sus metadatos asociados consistentes entre sí es importante para su aplicación, entonces las transacciones que puede proporcionar un DB pueden ser una bendición.
Un sistema para administrar. ¿Necesita hacer una copia de seguridad de los metadatos y blobs? Copia de seguridad de la base de datos. ¿Necesitas replicarlos? Replicar la base de datos. ¿Necesita recuperarse de una falla parcial del sistema? Recargue la base de datos y haga rodar los registros hacia adelante. Todas las ventajas que los DB aportan a los datos en general (asignación de volúmenes, control de almacenamiento, copias de seguridad, replicación, recuperación, etc.) se aplican a sus blobs. Más consistencia, manejo más fácil.
Seguridad. Las bases de datos tienen características de seguridad muy finas que pueden aprovecharse. Esquemas, roles de usuario, incluso cosas como "vistas de solo lectura" para brindar acceso seguro a un subconjunto de datos. Todas estas características funcionan con tablas que también contienen blobs.
Gestión centralizada Relacionado con el # 2, pero básicamente los DBA (como si no tuvieran suficiente energía) logran administrar una cosa: la base de datos. Las bases de datos modernas (especialmente las más grandes) funcionan muy bien con grandes instalaciones en varias máquinas. Una única fuente de gestión simplifica los procedimientos, simplifica la transferencia de conocimientos.
La mayoría de las bases de datos modernas manejan blobs muy bien. Con soporte de primera clase de blobs en su nivel de datos, puede transmitir fácilmente blobs desde el DB al cliente. Si bien hay operaciones que puedes hacer que "absorberán" todo el blob de una sola vez, si no necesitas esa instalación, entonces no la uses. Estudie la interfaz SQL para su base de datos y aproveche sus características. No hay razón para tratarlos como "grandes cadenas" que se tratan de forma monolítica y convierten sus blobs en grandes, la memoria que devora, las bombas que rompen la memoria caché.
Al igual que puede configurar servidores de archivos dedicados para imágenes, puede configurar servidores de blob dedicados en su base de datos. Déles volúmenes de disco dedicados, esquemas dedicados, cachés dedicados, etc. Todos sus datos en la base de datos no son los mismos, o se comporta igual, no hay razón para configurarlo de todos modos. Las buenas bases de datos tienen un buen nivel de control.

El objetivo principal con respecto a la publicación de un blob desde un DB es garantizar que su capa HTTP realmente aproveche todo el protocolo HTTP para realizar el servicio.

Muchas implementaciones ingenuas simplemente toman el blob y lo descargan al por mayor. Pero HTTP tiene varias características importantes adecuadas para la transmisión de imágenes, etc. Notablemente, los encabezados de almacenamiento en caché, ETags y transferencia fragmentada permiten a los clientes solicitar "piezas" del blob.

Asegúrese de que su servicio HTTP cumpla adecuadamente todas esas solicitudes, y su base de datos puede ser un buen ciudadano de la Web. Al almacenar en caché los archivos en un sistema de archivos para que los sirva el servidor HTTP, usted obtiene algunas de esas ventajas "gratis" (ya que un buen servidor lo hará de todos modos para recursos "estáticos"), pero asegúrese de que si lo hace, usted honrar cosas como fechas de modificación, etc. para imágenes.

Por ejemplo, alguien solicita spaceshuttle.jpg, una imagen creada el 1 de enero de 2009. Eso termina en caché en el sistema de archivos en la fecha de solicitud, por ejemplo, el 1 de febrero de 2009. Más tarde, la imagen se borra del caché (política FIFO , o lo que sea), y alguien, más tarde, el 1 de marzo de 2009 lo solicita nuevamente. Bueno, ahora tiene una "fecha de creación" del 1 de marzo de 2009, aunque todo el tiempo su fecha de creación fue realmente el 1 de enero. Entonces, puede ver, especialmente si su caché gira mucho, los clientes que pueden estar usando If- Los encabezados modificados pueden obtener más datos de los que realmente necesitan, ya que el servidor PIENSA que el recurso ha cambiado, cuando en realidad no lo ha hecho.

Si mantiene la fecha de creación de la memoria caché sincronizada con la fecha de creación real, esto puede ser un problema menor.

Pero el punto es que es algo para pensar sobre todo el problema para ser un "buen ciudadano de la web", y ahorrarle a usted y a sus clientes potencialmente algo de ancho de banda, etc.

Acabo de analizar todo esto para un proyecto Java que sirve videos de un DB, y todo funciona de maravilla.

Si en alguna ocasión necesita recuperar una imagen, debe estar disponible en varios servidores web diferentes. Pero creo que eso es más o menos.

Si no tiene que estar disponible en varios servidores, siempre es mejor colocarlos en el sistema de archivos.
Si tiene que estar disponible en varios servidores y hay algún tipo de carga en el sistema, necesitará algún tipo de almacenamiento distribuido.

Estamos hablando de un caso extremo aquí, donde puede evitar agregar un nivel adicional de complejidad a su sistema aprovechando la base de datos.

Aparte de eso, no lo hagas.

Si se trata de imágenes que se extraen regularmente de la base de datos, siempre trataré de usar el sistema de archivos.

Si se tratara de imágenes que deben extraerse de vez en cuando, y guardarlas en la base de datos hace la vida más fácil, no tengo ningún problema con esto.

Si su aplicación se ejecuta en varios servidores, almacenaría la copia de referencia de sus imágenes en la base de datos y luego las almacenaría en la memoria caché en los sistemas de archivos. Hacerlo es mucho menos un error en el trasero que tratar de sincronizar los sistemas de archivos lateralmente.

Si su aplicación está en un solo servidor, entonces, sígale al sistema de archivos y haga que la base de datos mantenga una ruta a los datos.

Una de las ventajas de almacenar imágenes en la base de datos es que es portátil en todos los sistemas e independiente en el diseño del sistema de archivos.

la recuperación de desastres no es nada divertida cuando tienes terabytes de datos de imágenes almacenados en la base de datos. Es mejor que encuentres una forma mejor de distribuir tus datos para hacerlo más confiable, etc. Por supuesto, todos los gastos generales (mencionados anteriormente) se multiplican al replicar y así sucesivamente ...

¡Simplemente no lo hagas!

base de datos para datos
sistema de archivos para archivos