¿Debo guardar mis imágenes en la base de datos o en las carpetas?

Posible duplicado:
Almacenar imágenes en DB – ¿Sí o No?

Hola

Actualmente, cada empresa de mi sitio web tiene 1 foto que pueden agregar a su perfil. Guardo esa imagen en la base de datos … es su logotipo de la empresa.

Ahora quiero permitirles agregar más imágenes. Ahora no sé si debo guardarlo todo en la base de datos o guardarlo en carpetas ???

La razón por la que creo que las carpetas serán mejores es porque hay tantos artículos bonitos con luces plateadas extravagantes que puedo usar, pero todos solo atienden las imágenes guardadas en carpetas.

Y dado que no soy tan bueno, es difícil para mí cambiar el código para mirar la base de datos en lugar de los ejemplos que usan carpetas para la recuperación de imágenes.

Me gustaría agregar algo como esto a mi sitio web (navegar a través de las imágenes). ¿Algún ejemplo de código para mí sobre cómo hacer esto cuando las imágenes se guardan en la base de datos? Estoy usando ASP.NET con VB.net. Haga clic aquí para ver de lo que estoy hablando

Alguna idea chicos?

Saludos Etienne

Lo he hecho en ambos sentidos recientemente. Prefiero usar el método de directorio para almacenar las imágenes mientras mantengo sus propiedades en un DB.

Motivo principal: tenía un cliente para el que hice un sitio web. Había una sección de galería de fotos que les permitía subir nuevas fotos que podían ser vistas desde el sitio público. Mi cliente no pensó en optimizar sus imágenes antes de subirlas. Así que básicamente cada .jpg tenía más de 1mb. Agregué la capacidad de actualizar una imagen una vez que se guardó en la base de datos pero tenía que hacerse un registro a la vez.

Si ocurriera lo mismo al almacenar las imágenes en un directorio, los archivos podrían guardarse localmente, optimizarse y volver a colocarse en el servidor.

Aquí hay un ejemplo

Buscaría carpetas. Más flexibilidad si se queda sin espacio de almacenamiento (simplemente muévalos a otro disco y vuelva a enfocar), más flexibilidad con otras aplicaciones (por ejemplo, Silverlight). Solo usaría DB para archivos que tenían que ser seguros.

Para cualquier sitio normal, usted absolutamente quiere esto como parte de la aplicación del sitio en sí, no almacenada en un DB. Un sitio web debe contenerse tanto como sea posible para mantenerlo portátil, y no agregar viajes redondos al DB (incluso en el almacenamiento en caché) solo puede ser algo bueno. Los servidores web son muy buenos para servir archivos de imagen.

Sin embargo, personalmente estoy trabajando en una aplicación donde las imágenes se crean dinámicamente y se ponen a disposición del sitio a través de una segunda aplicación de administración. Claramente, estos deben estar respaldados por DB de alguna forma para mantener las imágenes mantenibles y seguras.

En pocas palabras, donde las imágenes tienen valor comercial (es decir, están contenidas, necesitan seguridad o son dinámicas), tendrá que almacenarlas en una base de datos. Donde son estáticos y triviales, que el sitio web sea un sitio web.

Dos pensamientos sobre esto:

  1. Usa el sistema de archivos. Pero asegúrese de diseñar su esquema lo suficientemente bien como para que cualquier carpeta no se sobrecargue con imágenes y se convierta en una pesadilla para administrar. Por ejemplo, puede ramificarlo con la primera o la última letra del identificador, o la siguiente notación posicional. Su millaje variará, así que asegúrese de que el esquema se ajuste a su tamaño de conjunto de datos (imágenes). No necesita ir a longitudes detalladas si solo está administrando, digamos, 20 imágenes.

  2. Use SQL Server 2008. Tiene un nuevo tipo de datos llamado filestream, mientras que guardará las imágenes en el sistema de archivos pero le permitirá recuperarlas mediante consultas de bases de datos estándar. Consulte http://msdn.microsoft.com/en-us/library/cc949109.aspx para obtener más información.

Estas no son opciones exclusivas, pero al menos recomiendo la opción n. ° 1 por el simple hecho de que obtendrás un mejor rendimiento al usar un esquema basado en el sistema de archivos en lugar de almacenar y leer blobs de una base de datos. .

Creo que guardar imágenes en las carpetas del sistema es la mejor manera.
trabajar con DB y consultas que usted sabe causará algunas sobrecargas y las transiciones de DB generalmente son pesadas y puede poner más estrés en su servidor.
con la forma en que guardas las imágenes en carpetas y simplemente colocas las URL en DB, es más adecuado para tus cargas de aplicaciones.
pero la ventaja de DB es que puedes hacer copias de seguridad de tus imágenes.


Mi sugerencia: guarda tus imágenes en carpetas. la única necesidad es conocer las operaciones de E / S del sistema.

El enfoque que generalmente uso es copiar imágenes en una carpeta y mantener las URL relativas en la base de datos. La desventaja de este enfoque es que si alguien elimina las imágenes, termina con “imagen no encontrada” en sus páginas web, a menos que lo compruebe cada vez que renderice una página.

Tenía la misma pregunta para mi sitio también. Decidí usar la implementación de la carpeta, porque si usas la base de datos, cuando deseas hacer una copia de seguridad de las fotos debes hacer una copia de seguridad de toda la base de datos … por otro lado puedes mantener la estructura del directorio y hacer una copia de seguridad fácil .

Separar cosas mi amigo, mis mejores deseos!

AFAIK, flickr.com va con carpetas / servidor de archivos también con la referencia, metadatos, etc. almacenados en db. Ver la architecture de flickr

La ventaja de utilizar carpetas es que no necesita tener un controlador personalizado que saque esos BLOB de una base de datos y los convierta en flujos regulares. También es más sencillo alojarlos desde diferentes ubicaciones y evitará la carga en el servidor de la base de datos.

Tienes que tener cuidado con el almacenamiento de los nombres de las rutas. Las rutas de acceso relativas funcionan mejor como URL y le permitirán cierta flexibilidad y escalado en el lugar donde las almacena, cómo las sirve, etc.

Iré por ambos.

En primer lugar, almacene cada imagen como una columna BLOB en la base de datos. Al hacerlo, puede estar seguro de que la imagen siempre se incluye en la copia de seguridad de su base de datos (suponiendo que lo haga).

En segundo lugar, copie el archivo en la carpeta. Al hacerlo, puede evitar realizar consultas en la base de datos (para el archivo de imagen) cada vez. Almacenar solo en la carpeta puede tener implicaciones tales como

  • archivo perdido debido a un disco dañado
  • archivo no están incluidos en la operación de copia de seguridad

Hasta ahora, todos nuestros proyectos de clientes están tomando el mismo enfoque y hemos encontrado varios problemas, pero no se pierden archivos cargados. (Estamos hablando de> 100 GB de documentos cargados).

Tenga en cuenta que es posible que desee consultar lo siguiente:

  1. Asegúrese de que cada vez que el archivo se actualice / reemplace, hágalo en la base de datos y en la carpeta. De lo contrario, será inconsistente.
  2. Es posible que desee tener una tabla separada para almacenar la información del archivo. En general, es posible que desee almacenar lo siguiente: (1) nombre de archivo (2) tipo de archivo (3) tamaño de archivo / tipo mime
  3. Es posible que desee dividir las tablas que almacenan datos. Nuestra práctica es que una vez que la tabla scope los 2GB, creamos otra tabla. Diseñado correctamente, no debería haber ningún problema para encontrar la mesa correcta.

Espero que esto ayude.