Campo Image Vs Imágen independiente

Respuestas en línea...
"Maxi" escribió en el mensaje
news:

Carlos, y como haces cuando debes por ej pasar la base de un lugar a otro,
donde ese otro es por ej una notebook que necesita esta offline? me

imagino

que empezas con backup y restore de bdd y ademas haces un backup de

imagenes

y ademas debes cambiar ese ini de ubicacion verdad?

costosa, verdad? La idea no es estar cambiando la ubicación de mi base de
datos cada dos por tres

Como has resuelto el tema de reportes donde es necesario imprimir la

imagen

? por ej un Cristal Report

(gracias a Dios), así que no puedo contestarte a esa problemática. Mis
aplicaciones son web, así que yo siempre le digo la ruta virtual de esa
imagen...

Y con respecto a la performance (PROBALO) ;-)

página web) en leer de la base de datos, transformar ese texto image y
pintarlo, que en poner directamente la ruta virtual del archivo? Pues no sé,
tendré que probarlo, pero antes tendré que investigar en cómo se hace desde
java, que es lo que yo uso :-S


Un saludo

-
"Sólo sé que no sé nada. " (Sócrates)

Carlos, proiba www.mug.org.ar, esta todo asi como te digo (imagenes,
documentos, etc) todo en la bdd y en .net :-)


Salu2
Maxi [MVP SQL SERVER]


"Carlos Sacristán" <csacristanARROBAmvpsPUNTOorg> escribió en el mensaje
news:%

Respuestas en línea...
"Maxi" escribió en el mensaje
news:

Carlos, y como haces cuando debes por ej pasar la base de un lugar a
otro,
donde ese otro es por ej una notebook que necesita esta offline? me

imagino

que empezas con backup y restore de bdd y ademas haces un backup de

imagenes

y ademas debes cambiar ese ini de ubicacion verdad?

costosa, verdad? La idea no es estar cambiando la ubicación de mi base de
datos cada dos por tres

Como has resuelto el tema de reportes donde es necesario imprimir la

imagen

? por ej un Cristal Report

(gracias a Dios), así que no puedo contestarte a esa problemática. Mis
aplicaciones son web, así que yo siempre le digo la ruta virtual de esa
imagen...

Y con respecto a la performance (PROBALO) ;-)

página web) en leer de la base de datos, transformar ese texto image y
pintarlo, que en poner directamente la ruta virtual del archivo? Pues no
sé,
tendré que probarlo, pero antes tendré que investigar en cómo se hace
desde
java, que es lo que yo uso :-S


Un saludo

-
"Sólo sé que no sé nada. " (Sócrates)

La desventaja que agrego cuando las imágenes están en la base de datos son:

1. Backup y restore más costosos, o necesidad de organizar filegroups y
pasarme a un esquema de respaldo estilo VLDB que son más complejos de
administrar para un DBA. Para las imágenes en el file system, uso mecanismos
de backup con herramientas para file system (hay muy rápidos y buenos) y el
file system está optimizado para almacenar archivos de imágenes (mejor
ajuste del parámetro de allocation unit, buena defragmentación y puesto en
un subsistema rápido de disco).

2. Mantenimiento más costos de las imágenes. Si están en el file system las
imágenes pueden ser manipuladas y versionadas fácilmente por las
herramientas de tratamiento de imágen que usan los diseñadores gráficos. Un
cambio simple como ser: a la imagen X le quiero modificar un poco la gama de
colores rojos; o le quiero cambiar el tamaño o la profundidad de pixeles.
Eso puede hacer simplemente abriendo la imagen en el editor de gráficos...
pero si está en la base d edatos hay que hacer una aplicación que extraiga
la imagen, la modifique el diseñador y luego volverla a insertar en la base.

3. Acceso a la metadata de la imagen. Tenemos la consulta frecuente: quiero
saber cuáles son las imágenes de X tamaño, formato .TIFF, escaneadas el mes
pasado por el scanner modelo Y. Esa data es fácilmente consultable por
propiedades físicas de la imágen y no se almacenan con los demás datos
relacionales. Y si esperamos, tendremos esas bondades más fácilmente
resueltas en el próximo file system de Windows Vista Server.

El tema de rendimiento en el acceso al file system que tengo es excelente,
al igual que menciona Carlos, son páginas y documentos accesibles desde un
sitio web.

Todos los puntos que ha mencionado Maxi: o bien no los tengo como
desventajas. o bien los he solucionado eficientemente. Sin embargo estos 3
puntos que planteo no le encuentro solución en la propuesta de almacenar las
imágenes en la propia base.

Un abrazo amigazos,
~gux

Gustavo Larriera
Uruguay LatAm
Blog: http://sqljunkies.com/weblog/gux/
MVP profile: http://aspnet2.com/mvp.ashx?GustavoLarriera
Este mensaje se proporciona "COMO ESTA" sin garantias y no otorga ningun
derecho / This posting is provided "AS IS" with no warranties, and confers
no rights.
"Carlos Sacristán" <csacristanARROBAmvpsPUNTOorg> wrote in message
news:%

¿Más rápido? No sé, me cuesta creerlo, aunque no dudo de tu palabra...

Las ventajas que le veo yo son, indudablemente, de manejo de los datos
y
de simplicidad del sistema: la aplicación no se tiene que encargar de
enviar/recibir y transformar todos los bytes que conforman el archivo cada
vez que se manipule porque dicho archivo ya existe. De este modo me evito
tener que hacer una operación incuestionablemente (aunque para tí sea más
sencillo porque estás acostumbrado a su manejo) más costosa que presentar
el
archivo que se encuentra en la ruta que la base de datos proporciona.

Si cambia la ubicación del archivo no tengo problemas porque yo sólo
almaceno el nombre del mismo, y el resto de la ruta me la proporciona otro
parámetro (leído de una tabla, de una función, etc)

Windows tiene su propia seguridad que puedo implementar como necesite
(el ejemplo que le puso Gustavo es perfecto)

Las copias de seguridad también me las proporciona Windows.

En fin, que de momento no he necesitado almacenar archivos en la base
de
datos y sin embargo, como a tí, me ha ido muy bien...


Un saludo

-
"Sólo sé que no sé nada. " (Sócrates)

"Maxi" escribió en el mensaje
news:uVuH#

jaja, como te gusta discutir ;-), es mas eficiente aunque no lo creas (yo
jamas lo habia creido hasta que lo probe), si tienes muchos archivos el
engine de SQL es muy rapido comparado con el filesystem :-)

Ademas, ustedes que defienden la otra postura ;-), cuales son las
ventajas
enormes que le ven ??


Salu2
Maxi [MVP SQL SERVER]


"Carlos Sacristán" <csacristanARROBAmvpsPUNTOorg> escribió en el mensaje
news:%
> ¿Más eficiente? Pues ahí permite que lo dude, no creo que sea más
> rápido
> leer el registro de la base de datos, transformarlo y luego mostrarlo

con

> la
> aplicación que sea que simplemente abrir el archivo en cuestión
> directamente
> de la ruta indicada...
>
> Bueno, era más que nada por seguir discutiendo, que es divertido
> ;-)
>
> Yo estoy más del lado de Gustavo...
>
>
> Un saludo
>
> -
> "Sólo sé que no sé nada. " (Sócrates)
>
> "Maxi [MVP SQL Server]" escribió en el
> mensaje news:#
>> Gux, no estoy cerrado ni mucho menos!!! solo te comento los problemas
>> q
>> siempre he tenido :(. Ya sabemos q este tema es bastante calentito

porque

> no
>> habra 2 opiniones iguales ni formas de pensar, acepto tu planteo, pero
>> por
>> experiencia sigo guardando las imagenes en la bdd, aunque no lo creas

es

>> mucho mas eficiente que en los filesystem cuando tenes muchas de
>> estas.
>> Antes lo hacia como vos indicas ;-)
>>
>>
>> [Microsoft MVP SQL SERVER]
>> Culminis SQL-Server Speakers (http://latam.culminis.com)
>>
>> Maxi - Buenos Aires - Argentina
>> Msn_messager:
>> mail: Maxi.da[arroba]gmail.com
>>
>> "Gustavo Larriera [MVP]" escribió en el
>> mensaje
>> news:
>> > Veo que estás cerrado a tu solución y no ves otra posibilidad...
> permitime
>> > insistir un poco más :-)
>> >
>> > "Maxi [MVP SQL Server]" wrote in
>> > message
>> > news:
>> >> Gux, hay algo que no podes solucionar y es la integridad entre

imagen

>> >> y
>> >> bdd, por mas que pongas los permisos que quieras, si alguien cambia
> algo
>> >> en el filesystem la bdd no se entera :(, en sistemas documentales

esto

> es
>> >> una falta mas que grave :(
>> >
>> > Capaz que no entendiste mi solución:
>> >
>> > ?Cómo habría alguien de cambiar algo en el filesystem si cierro los
>> > permisos para que únicamente la cuenta de dominion del servicio SQL
> Server
>> > acceda a la carpeta de imágenes?
>> >
>> > Y además confío plenamente en la persona que es el Administrador del
>> > sistema que no va a andar jugando con los permisos y rompiendo las
>> > carpetas de las aplicaciones.
>> >
>> > Así como tú deberás confiar en tu DBA para que no haga destrozos con
>> > las
>> > imágenes almacenadas en la propia base d edatos según propones,

cierto?

>> >
>> >>
>> >> El punto 3 hacia referencia no solo a sistemas distribuidos sino
>> >> mas

a

>> >> sistemas donde se ejecuta el sql desde la aplicacion. Si ejecutas
>> >> el
>> >> select desde la aplicacion vas a buscar la ruta y el archivo y con

eso

> el
>> >> servicio debera tener acceso a la ubicacion para poder leer dicha
> imagen,
>> >> el motor no sabe nada de la imagen por lo cual la aplicacion se
>> >> debe
>> >> hacer cargo, tanto en seguridad como en el resto. Ahora si usas
>> >> 100%
> Sp's
>> >> la cosa cambia, pero no es en todos los casos asi :(
>> >
>> > Para solucionar eso es que existen los shared folders que mencioné.
>> >
>> > Saludos
>> > ~gux
>> >
>>
>>
>
>

Jjeje, vamos a estar discutiendo toda una decada ;-)

1. Backup y restore más costosos, o necesidad de organizar filegroups y
pasarme a un esquema de respaldo estilo VLDB que son más complejos de
administrar para un DBA. Para las imágenes en el file system, uso
mecanismos de backup con herramientas para file system (hay muy rápidos y
buenos) y el file system está optimizado para almacenar archivos de
imágenes (mejor ajuste del parámetro de allocation unit, buena
defragmentación y puesto en un subsistema rápido de disco).

Como bien dijiste, con filegroups, para eso estan y funcionan de mil
maravillas

2. Mantenimiento más costos de las imágenes. Si están en el file system las

imágenes pueden ser manipuladas y versionadas fácilmente por las
herramientas de tratamiento de imágen que usan los diseñadores gráficos.
Un cambio simple como ser: a la imagen X le quiero modificar un poco la
gama de colores rojos; o le quiero cambiar el tamaño o la profundidad de
pixeles. Eso puede hacer simplemente abriendo la imagen en el editor de
gráficos... pero si está en la base d edatos hay que hacer una aplicación
que extraiga la imagen, la modifique el diseñador y luego volverla a
insertar en la base.

Es muy pero muy relativo, una cosa es guardar imagenes donde se piensa
actualizar constantemente y se requiere ademas de un soft tipo photoshop
para administrarlas y otra cosa es si esas imagenes son mas estables o no
requieren semejante soft, por ej: fotos de empleados, documentos pdf,
documentos word, etc.
Ademas si queres podes tambien solucionarlo, nada impide que la imagen en la
base no la pueda manipular un photosahop, deberias obviamente armar algo
para extraer esa imagen y darla al cliente, este trabaja offline y luego la
inserta. En el otro modelo que vos decis es valido la modificacion de forma
simple pero.. (siempre hay uno ;-)) deberias asegurar esto, que quiero
decir: yo como sistema quiero saber quie, cuando y porque modifico una
imagen y hasta podria llegar a necesitar guardar la imagen anterior para
comparaciones.

3. Acceso a la metadata de la imagen. Tenemos la consulta frecuente:
quiero saber cuáles son las imágenes de X tamaño, formato .TIFF,
escaneadas el mes pasado por el scanner modelo Y. Esa data es fácilmente
consultable por propiedades físicas de la imágen y no se almacenan con los
demás datos relacionales. Y si esperamos, tendremos esas bondades más
fácilmente resueltas en el próximo file system de Windows Vista Server.

Sip, pero esto tambien lo podes hacer cuando la integras a la bdd, que te
impide tener la imagen en un campo y la cabecera de la misma con todos sus
atributos en otros campos?

Pero repito (y vos mas que yo lo sabes ;-)) esta discusion puede terminar en
10 decadas, es otro clasico :-), es como discutir si SP o no SP ;-)


Salu2
Maxi [MVP SQL SERVER]


"Gustavo Larriera [MVP]" escribió en el mensaje
news:%

La desventaja que agrego cuando las imágenes están en la base de datos
son:

1. Backup y restore más costosos, o necesidad de organizar filegroups y
pasarme a un esquema de respaldo estilo VLDB que son más complejos de
administrar para un DBA. Para las imágenes en el file system, uso
mecanismos de backup con herramientas para file system (hay muy rápidos y
buenos) y el file system está optimizado para almacenar archivos de
imágenes (mejor ajuste del parámetro de allocation unit, buena
defragmentación y puesto en un subsistema rápido de disco).

2. Mantenimiento más costos de las imágenes. Si están en el file system
las imágenes pueden ser manipuladas y versionadas fácilmente por las
herramientas de tratamiento de imágen que usan los diseñadores gráficos.
Un cambio simple como ser: a la imagen X le quiero modificar un poco la
gama de colores rojos; o le quiero cambiar el tamaño o la profundidad de
pixeles. Eso puede hacer simplemente abriendo la imagen en el editor de
gráficos... pero si está en la base d edatos hay que hacer una aplicación
que extraiga la imagen, la modifique el diseñador y luego volverla a
insertar en la base.

3. Acceso a la metadata de la imagen. Tenemos la consulta frecuente:
quiero saber cuáles son las imágenes de X tamaño, formato .TIFF,
escaneadas el mes pasado por el scanner modelo Y. Esa data es fácilmente
consultable por propiedades físicas de la imágen y no se almacenan con los
demás datos relacionales. Y si esperamos, tendremos esas bondades más
fácilmente resueltas en el próximo file system de Windows Vista Server.

El tema de rendimiento en el acceso al file system que tengo es excelente,
al igual que menciona Carlos, son páginas y documentos accesibles desde un
sitio web.

Todos los puntos que ha mencionado Maxi: o bien no los tengo como
desventajas. o bien los he solucionado eficientemente. Sin embargo estos 3
puntos que planteo no le encuentro solución en la propuesta de almacenar
las imágenes en la propia base.

Un abrazo amigazos,
~gux

Gustavo Larriera
Uruguay LatAm
Blog: http://sqljunkies.com/weblog/gux/
MVP profile: http://aspnet2.com/mvp.ashx?GustavoLarriera
Este mensaje se proporciona "COMO ESTA" sin garantias y no otorga ningun
derecho / This posting is provided "AS IS" with no warranties, and confers
no rights.
"Carlos Sacristán" <csacristanARROBAmvpsPUNTOorg> wrote in message
news:%

¿Más rápido? No sé, me cuesta creerlo, aunque no dudo de tu palabra...

Las ventajas que le veo yo son, indudablemente, de manejo de los datos
y
de simplicidad del sistema: la aplicación no se tiene que encargar de
enviar/recibir y transformar todos los bytes que conforman el archivo
cada
vez que se manipule porque dicho archivo ya existe. De este modo me evito
tener que hacer una operación incuestionablemente (aunque para tí sea más
sencillo porque estás acostumbrado a su manejo) más costosa que presentar
el
archivo que se encuentra en la ruta que la base de datos proporciona.

Si cambia la ubicación del archivo no tengo problemas porque yo sólo
almaceno el nombre del mismo, y el resto de la ruta me la proporciona
otro
parámetro (leído de una tabla, de una función, etc)

Windows tiene su propia seguridad que puedo implementar como necesite
(el ejemplo que le puso Gustavo es perfecto)

Las copias de seguridad también me las proporciona Windows.

En fin, que de momento no he necesitado almacenar archivos en la base
de
datos y sin embargo, como a tí, me ha ido muy bien...


Un saludo

-
"Sólo sé que no sé nada. " (Sócrates)

"Maxi" escribió en el mensaje
news:uVuH#

jaja, como te gusta discutir ;-), es mas eficiente aunque no lo creas
(yo
jamas lo habia creido hasta que lo probe), si tienes muchos archivos el
engine de SQL es muy rapido comparado con el filesystem :-)

Ademas, ustedes que defienden la otra postura ;-), cuales son las
ventajas
enormes que le ven ??


Salu2
Maxi [MVP SQL SERVER]


"Carlos Sacristán" <csacristanARROBAmvpsPUNTOorg> escribió en el mensaje
news:%
> ¿Más eficiente? Pues ahí permite que lo dude, no creo que sea más
> rápido
> leer el registro de la base de datos, transformarlo y luego mostrarlo

con

> la
> aplicación que sea que simplemente abrir el archivo en cuestión
> directamente
> de la ruta indicada...
>
> Bueno, era más que nada por seguir discutiendo, que es divertido
> ;-)
>
> Yo estoy más del lado de Gustavo...
>
>
> Un saludo
>
> -
> "Sólo sé que no sé nada. " (Sócrates)
>
> "Maxi [MVP SQL Server]" escribió en el
> mensaje news:#
>> Gux, no estoy cerrado ni mucho menos!!! solo te comento los problemas
>> q
>> siempre he tenido :(. Ya sabemos q este tema es bastante calentito

porque

> no
>> habra 2 opiniones iguales ni formas de pensar, acepto tu planteo,
>> pero
>> por
>> experiencia sigo guardando las imagenes en la bdd, aunque no lo creas

es

>> mucho mas eficiente que en los filesystem cuando tenes muchas de
>> estas.
>> Antes lo hacia como vos indicas ;-)
>>
>>
>> [Microsoft MVP SQL SERVER]
>> Culminis SQL-Server Speakers (http://latam.culminis.com)
>>
>> Maxi - Buenos Aires - Argentina
>> Msn_messager:
>> mail: Maxi.da[arroba]gmail.com
>>
>> "Gustavo Larriera [MVP]" escribió en el
>> mensaje
>> news:
>> > Veo que estás cerrado a tu solución y no ves otra posibilidad...
> permitime
>> > insistir un poco más :-)
>> >
>> > "Maxi [MVP SQL Server]" wrote in
>> > message
>> > news:
>> >> Gux, hay algo que no podes solucionar y es la integridad entre

imagen

>> >> y
>> >> bdd, por mas que pongas los permisos que quieras, si alguien
>> >> cambia
> algo
>> >> en el filesystem la bdd no se entera :(, en sistemas documentales

esto

> es
>> >> una falta mas que grave :(
>> >
>> > Capaz que no entendiste mi solución:
>> >
>> > ?Cómo habría alguien de cambiar algo en el filesystem si cierro los
>> > permisos para que únicamente la cuenta de dominion del servicio SQL
> Server
>> > acceda a la carpeta de imágenes?
>> >
>> > Y además confío plenamente en la persona que es el Administrador
>> > del
>> > sistema que no va a andar jugando con los permisos y rompiendo las
>> > carpetas de las aplicaciones.
>> >
>> > Así como tú deberás confiar en tu DBA para que no haga destrozos
>> > con
>> > las
>> > imágenes almacenadas en la propia base d edatos según propones,

cierto?

>> >
>> >>
>> >> El punto 3 hacia referencia no solo a sistemas distribuidos sino
>> >> mas

a

>> >> sistemas donde se ejecuta el sql desde la aplicacion. Si ejecutas
>> >> el
>> >> select desde la aplicacion vas a buscar la ruta y el archivo y con

eso

> el
>> >> servicio debera tener acceso a la ubicacion para poder leer dicha
> imagen,
>> >> el motor no sabe nada de la imagen por lo cual la aplicacion se
>> >> debe
>> >> hacer cargo, tanto en seguridad como en el resto. Ahora si usas
>> >> 100%
> Sp's
>> >> la cosa cambia, pero no es en todos los casos asi :(
>> >
>> > Para solucionar eso es que existen los shared folders que mencioné.
>> >
>> > Saludos
>> > ~gux
>> >
>>
>>
>
>