IMAGENES EN MYSQL

[Ariel]

Hola a todos,

Segun sus experiencias, que es mejor guardar la imagen, pdf, jgp, word, excell, etc en una tabla en un campo blob o guardar el enlace en un campo texto ?

Gracias,
Salu2, Ariel.

[Daniel Garcia-Gil]

Ariel

Para mi pensar no hay una regla estandar, todo dependera del proposito de la tabla y el campo BOLOB que pienses usar y de la cantidad de archivos (que pueden ser imagenes, documentos, etc) que pienses que puedas usar, del tamaño que puedan contener cada una, por ejemplo no es lo mismo almacenar las imagenes de banderas de los paises, que sabemos son limitadas, a guardar pfds con todas las faturas generadas de una tienda por departamento... otro caso, podrias guardar las imagenes de los empleados pero no documentos que contengan multiple informacion diaria sobre algun proceso comercial...

[Antonio Linares]

Sería muy interesante si todos los que usais ya MySQL nos comentais como guardais las imágenes

Podria vuestra aplicación "escalar" hasta manejar miles, millones de imágenes ? Como lo hariais ? Como lo estais haciendo ?

Y puestos a usar un "Hosting" que pudiese albergar toda esa cantidad enorme de imágenes, cual usaríais ?

A mi se me viene a la cabeza "Amazon" y "Google engine", no creo que ninguna otra solución sea capaz de manejar un volumen tan enorme de datos, pero me encantaría que compartais vuestras experiencias, gracias!

[Ariel]

Gracias por contestar,

Actualmente la situacion la tengo con dbfs, donde guardo el link de la imagen o pdf o lo que sea, pero estamos migrando el sistema a mysql entonces queria ver cual seria la mejor opcion.
Son muchas imagenes y pesadas, hay desde planos hasta facturas, en total hasta ahora van como 3 Gb de archivos de imagenes o pds o lo que sea q meten ahi.

Gracias.
Salu2, Ariel.

[Kleyber]

Bueno, en mi caso costumbro almacenar las imagenes en el banco de dados, por causa de la seguridad. Para almacenar imagenes en MySQL tiene estos tipos de campos: TINYBLOB, BLOB, MEDIUMBLOB, e LONGBLOB, que te premiten almacenar desde una imagen muy pequeña hasta una imagen muy grande (usando el tipo de campo LONGBLOB).

[Lautaro]

Hola,

En mis caso, tal como indica Kleyber, guardo las imagenes en el banco de datos por 2 causar : la primera la seguridad y la segunda la consistencia de los datos, ya que en algun momento nos ocurrio que hubo que cambiar las imagenes de ubicacion y en ese caso hay que actualizar todas las referencias a la imagen, lo que puede resultar muy trabajoso.

En lo práctico, nosotros creamos una tabla con los datos necesarios para referenciar la imagen y un campo blob ( en mysql) para guardar ahi la imagen, asi , si existe la necesidad de mover o hacer un respaldo de los datos, se pueden seleccionar segun algun criterio y salvo que la red sea muy lenta o la imagen muy grande, el proceso funciona muy bien. Eso si, nosotros guardamos la imagen a tamaño original y una miniatura, para hacer aun mas rápido el proceso de vista previa.

Saludos,

Lautaro Moreira

[cnavarro]

Hola,

... el proceso funciona muy bien. Eso si, nosotros guardamos la imagen a tamaño original y una miniatura, para hacer aun mas rápido el proceso de vista previa.

Saludos,

Lautaro Moreira

Muy buena idea

[Antonio Linares]

Lautaro,

nosotros guardamos la imagen a tamaño original y una miniatura

Puedes explicarnos cómo lo haces ó mostrarnos el código que usas ? gracias

[Carles]

Hola,

Partiendo de la base de que nosotros deseamos almacenar ficheros (imagenes,documentos,...) el principal problema radica en la cantidad de información que nuestra aplicación deberá gestionar y los recursos que tenemos. Si nosotros hemos de gestionar solo unos miles de registros la opción de un proveedor normal ya nos soluciona el problema, pero si somos conscientes de que necesitaremos escalar y cada vez mas rendimiento se ha de proveer un buen servicio como p..e 'amazon' del que uno no se preocupa de nada porque ellos mismos se encargan de gestionar el rendimiento de los servers y si necesitos mas capacidad, si hace falta 'te enchufan' otro y ni te enteras... peroooo.

Alerta con el diseño de las tablas de informacion. Sabemos q como diseñadores de aplicaciones de gestión, constantemente hacemos nuestras estadísticas, cálculos,... esto implica en que nos olvidemos de hacer los 'select * ...' en tablas con blob, debemos p.e. tener tablas con id / blob que hagan referencia a otras. Este simple tip en bases de datos pequeñas no se nota en rendimiento pero si en tablas de millones de registros.

Es como usar dbfs en red, unos cuantos miles de registros no se nota en la ejecucion de un programa pero en un entorno de millones de registros es inviable, por lo que tienes q buscar otras soluciones.

Despues hay otro punto importante a tener en cuenta y que es por ejemplo como acceder desde fuentes externas p.e. una app a una imagen. Resulta mas fácil acceder al fichero via ftp o una uri que con el acceso directo a la base de datos. Se consulta a la base de datos q identificador tiene el fichero y posteriormente lo lees.

En el diseño de un sistema documental rapidamente haces una pelota de gigas de datos y a mi me preocupa mucha la integradad de la base de datos, tuve hace tiempo un susto con la base de datos con campos blob y parecia que todo se habia "roto" (me acordabo de los ficheros memo de hace años y se jodian). No habia manera de arreglarla y era o todo o nada. Es por eso la importancia en sistemas con millones de registros y volumen de datos un servicio que te asegure unos iops minimos, unas copia diarias automatizadas, replicaciones, escalados automaticos en rendimiento y seguridad,...

Actualmente uno de los sistemas que uso en mi trabajo esta basado en mysql y todo el tema de documentacion (imagenes y documentos) estan hospedados en carpetas que accedo via ftp desde el cliente. Via web cuando se reciben los datos se almacenan en mysql y los ficheros se renombran y en carpetas. Via app leo rápidamente la bd y si necesito el fichero lo cojo desde una uri. El sistema funciona perfectamente y pienso que la catastrofe de romper la bd, la dejo mas aparcada y el mayor de los males podria ser un fichero corrupto, 'perdido',... (q lo podria rescatar de las copias de seguridad)....

[Antonio Linares]

Carles,

Muy buena explicación, gracias!

[Ariel]

Carles,

podrias indicar como accedes x ftp al archivo de imagen o documento ? Normalmente en mis redes el servidor solo accedo x el ip a la bd no a carpetas...


Gracias.
Salu2, Ariel.

[Carles]

Ariel,

Que te refieres ? Como accedo desde FWH ? o como crear un servidor ftp ?

[Ariel]

Carles,

me refieron a como accedes al archivo de imagenes o documento via ftp?

salu2, Ariel.

[Carles]

Ariel,

Ejemplo base

Code: Select all

#include 'fivewin.ch'

#define MY_FTP  "vmweb"
#define MY_USER "cpit"
#define MY_PASW "xxxxxxx'"
#define BUFFER  2000

STATIC oInternet, oFtp

FUNCTION Main()

    LOCAL nOption

    IF !Conecta()
       RETU NIL
    ENDIF

    WHILE ( nOption := Alert( "take an option",;
                       { "&Envia Fitxer", "&Get Fitxer", "T&hree" },;
                       "Please, select" ) ) <> 0

       DO CASE
          CASE nOption == 1 ; EnviaFitxer()
          CASE nOption == 2 ; GetFitxer()
       ENDCASE

    END
    
RETU NIL

*------------------------
STATIC FUNCTION Conecta()
*------------------------

   MsgRun( "Conectant FTP...", "Per favor espera...",;
           { || oInternet := TInternet():New(),;
                If( Empty( oInternet:hSession ),;
                MsgAlert( "Sessio Internet no disponible!" ),),;
                oFTP := TFTP():New( MY_FTP, oInternet, MY_USER, MY_PASW ) } )

   IF Empty( oFTP:hFTP )
      MsgStop( "No puc conectar al FTP !", "Sistema" )
      RETU .F.
   ENDIF

RETU .T.


*----------------------------
STATIC FUNCTION EnviaFitxer()
*----------------------------
    LOCAl cFile := Upper( cGetFile( '*.*' ) )

    IF !File( cFile )
       RETU NIL
    ENDIF

    SendFile( cFile )

    MsgInfo( 'Done!' )

RETU NIL

*--------------------------------
STATIC FUNCTION SendFile( cFile )
*--------------------------------
    LOCAL hSource
    LOCAL oFile
    LOCAL cDesti   := cFileNoPath( cFile )
    LOCAL nBytes
    LOCAL cBuffer  := Space( BUFFER )

    hSource := FOpen( cFile )

    oFile = TFtpFile():New( 'dummy/' + cDesti, oFTP )
    oFile:OpenWrite()

    FSeek( hSource, 0, 0 )

    while ( nBytes := FRead( hSource, @cBuffer, BUFFER ) ) > 0

       oFile:Write( SubStr( cBuffer, 1, nBytes ) )

       SysRefresh()
    end

    FClose( hSource )

    oFile:End()

RETU NIL

*--------------------------
STATIC FUNCTION GetFitxer()
*--------------------------
    LOCAL hTarget
    LOCAL oFile
    LOCAL nBytes
    LOCAL cBuffer  := Space( BUFFER )
    LOCAL cFitxer  := 'A002.jpg       '
    LOCAL cDesti   := 'DOWNLOAD/'

    IF !MsgGet( 'A TENIR EN COMPTE MAJUSCULES/MINUSCULES', 'Nom', @cFitxer )
       RETU NIL
    ENDIF

    cFitxer := Alltrim( Upper( cFitxer ) )

    cDesti  := 'DOWNLOAD/' + cFitxer

    hTarget = FCreate( cDesti )

    oFile = TFtpFile():New( 'dummy/' + cFitxer, oFTP )
    oFile:OpenRead()

    IF oFile:hFile == 0
       Msginfo( 'Fitxer origen no existeix' )
       retu nil
    ENDIF

    while ( nBytes := Len( cBuffer := oFile:Read( BUFFER ) ) ) > 0

       FWrite( hTarget, cBuffer, nBytes )
       SysRefresh()

    end

    FClose( hTarget )

    oFile:End()

    Msginfo( File( cDesti ), 'Fitxer: ' + cDesti )

RETU NIL