imagenes en una BD de SQLServer

Bueno, quizas tengamos conceptos distintos de escalabilidad :), tambien es
la posibilidad de tener un server p4 y subir a un x64 tocando lo menos
posible la aplicacion, o bien si tengo una FASTI y quiero migrar a otra
FASTI que pueda escalar de HW sin cambiar casi nada en la aplicacion, si las
imagenes las tengo apuntadas a un filesystem de seguro tendre que cambiar
esa ruta si quiero cambiar el entorno del HW. Pero bueno son maneras de ver
las cosas o hasta conceptos errados :(
Tambien en temas de mantenimiento es mejor para mi la imagen dentro, en
modelos de disaster recovery puede ayudar mucho y con mirror en 2005 ni la
aplicacion tocas :) (con cluster es cierto q tampoco pero es mas cotoso
claro ;)


Saludos

[Microsoft MVP SQL Server]
www.sqlgurus.org
Buenos Aires - Argentina
"Miguel egea" wrote in message
news:%

Maxi, con todos mis respetos, eso que dices no es escalabilidad, vamos
por partes.

Separar en filegroups puede mejorar el rendimiento para tu situación, pero
como hemos discutido muchas veces, por la arquitectura de SQL las imágenes
se grabarán 2 veces una en el log y otra en los archivos de datos, por
tanto es al menos el doble de coste de disco (es más incluso).

Escalar implica que se admitan más conexiones, y metiendo las imágenes en
la base de datos jamás jamás jamás hará que sea más escalable.

¿escalar hacia arriba? Te refieres a ¿ escalabilidad vertical? confundes
el concepto, eso solo quiere decir que se puede poner una máquina más
grande.

Tenerlo en el filesystem implica quizá una pequeña sobrecarga en el
control de permisos y todo esto es cierto, pero consumirá casi seguro
menos recuros

Lo demás que dices puede afectar a la disponibilidad (nunca a la
escalabilidad) pero aún así es mucho más que discutible.

En resumen, creo que simplemente tienes un error de conceptos, eso que
describes puede ser muchas cosas ,pero nunca nunca es escalabilidad.

En cualquier caso yo no estoy ni de acuerdo ni en desacuerdo con meter
imágenes y o documentos en la BBDD. Solo que me sorprendío muchísimo que
dijeses que es más escalable. No lo es, te equivocas, has confundido el
concepto, pero :-) no pasa nada..

Saludos
Miguel Egea


"Maxi" wrote in message
news:%

Hola, claro que me ha solucionado problemas de escalabilidad, por ej de
cambiar de un server a otro y lo unico que cambie en las aplicaciones fue
la cadena de conexion, tambien me ha permitido en casos donde queria
tener mas fino el tunig separar en filegroups.
En otras palabras pude escalar hacia arriba en los servers sin mucho
esfuerzo desde el lado de las aplicaciones, me ha pasado tambien en
planes de contingencia que me ha ayudado bastante ya que hice un restore
en otro server y tenia todo funcionando de inmediado. O sea, a nivel
administrativo para mi es una ventaja y tambien me ha pasado en varios
clientes que algunos auditores me han cuestionado de tener los documentos
sin control , o sea: como se entaraba la aplicacion que en el filesystem
habia un cambio, se que es un tema muy discutido de hecho yo antes lo
ponia fuera, pero cuando espece a despejar algunas cuestiones como que
decian q era lento, etc, etc, eso jamas me ha pasado y pude ver que
SQLServer esta bien preparado para trabajar con este tipo de datos
dentro, de hecho ahora en 2005 se puede hacer lo mismo con el CLR, XML,
etc, estos reciden dentro y no hace referencia el motor a partes externas
:)


Saludos

[Microsoft MVP SQL Server]
www.sqlgurus.org
Buenos Aires - Argentina
"Miguel egea" wrote in message
news:%

¿eso te ha solucionado problemas de escalabilidad? De veras no imagino
como, meter esos objetos tiene ventajs e inconvenientes que hemos
discutido demasiadas veces, pero desde luego no mejoran en absoluto la
escalabilidad de un sistema., al menos yo no logro ver como


Saludos
Miguel Egea

"Maxi" wrote in message
news:

jjaa, sigo opinando y ejecutando lo mismo, objetos dentro de la bdd y
las imagenes tambien :) esto me ha solucionado problemas de
escalabilidad y tambien pude en algunos casos asegurar la operacion ya
que algunos audiores ISO me han traido dolores de cabeza con el otro
metodo ;)


Saludos

[Microsoft MVP SQL Server]
www.sqlgurus.org
Buenos Aires - Argentina
"Gustavo Larriera (MVP)" wrote in message
news:

SergioT wrote:

es buena idea separar la base de datos de imagenes de la de datos?
por el peso sobre todo,
influye en el desempeño de la consulta el hecho de tener imagenes
almacenadas en la BD y en otra BD

Que me sugieren para manejar las imagenes de la forma mas eficiente y
segura posible

Busca en este mismo foro, hemos discutido varias veces ese tema. Las
opiniones son diversas y todas válidas.

Personalmente, prefiero tener las imágenes almacenadas en el file
system y no en tablas de la base de datos.

El amigo Maxi opina lo contrario, si es que aún no se ha convencido de
algo mejor :-) :-) :-)


Gustavo Larriera, MVP
Solid Quality
MVP profile: http://aspnet2.com/mvp.ashx?GustavoLarriera
Blog: http://solidqualitylearning.com/blogs/glarriera/
Este mensaje se proporciona tal como es, sin garantías de ninguna
clase / This message is provided "AS IS" with no warranties expressed
or implied, and confers no rights.

Maxi wrote:

Bueno, quizas tengamos conceptos distintos de escalabilidad :)

Intentemos uniformizar los conceptos, somos profesionales de una
disciplina ingenieril, por tanto formal :-)

El término "escalabilidad" ha venido siendo cada vez más confuso debido
a los chicos de marketing que parecen tener una regla que dice "si no
decimos que el producto es escalable, nadie lo va a considerar" :-)

Desde el punto de vista estricto de la ingeniería de software, se define
"escalabilidad" como la habilidad que tiene un servicio de mantener su
nivel de rendimiento a pesar del crecimiento de consumidores que lo
acceden. En la definición, "servicio" y "consumidor" se usa en el
sentido más amplio de la palabra (puede ser cualquier componente que
ofrezca una funcionalidad a quien la consuma, sea un usuario,
dispositivo, aplicación, componente de hardware).

Muchos profesionales dicen que un sistema es escalable si es fácil de
adaptar o configurar a situaciones cambiantes del entorno. Este es un
concepto totalmente errado y no tiene que ver con escalabilidad. También
en ingeniería de software, esta porpiedad es "adaptabilidad" o
"configurabilidad" o "mantenibilidad". Pero no es "escalabilidad", por
cierto.

Son conceptos independientes. Un sistema puede ser escalable pero con
dificultades para configurarlo. Y a la inversa, un sistema puede ser
fácilmente configurable de un entorno a otro y sin embargo no ser
escalable (en el sentido de no soportar una carga adicional en el servicio).

Hay un lindo artículo de Dino Espósito que recomiendo ir a leer:

"Escalabilidad, dulce escalabilidad"
http://www.microsoft.com/spanish/ms...082001.asp

Saludos!
~gux


Gustavo Larriera, MVP
Solid Quality
MVP profile: http://aspnet2.com/mvp.ashx?GustavoLarriera
Blog: http://solidqualitylearning.com/blogs/glarriera/
Este mensaje se proporciona tal como es, sin garantías de ninguna clase
/ This message is provided "AS IS" with no warranties expressed or
implied, and confers no rights.

Maxi, no te sientas ofendido, escalabilidad no es eso, no hay más conceptos
que los que ha descrito gustavo.

Saludos
Miguel Egea

"Maxi" wrote in message
news:%

Bueno, quizas tengamos conceptos distintos de escalabilidad :), tambien es
la posibilidad de tener un server p4 y subir a un x64 tocando lo menos
posible la aplicacion, o bien si tengo una FASTI y quiero migrar a otra
FASTI que pueda escalar de HW sin cambiar casi nada en la aplicacion, si
las imagenes las tengo apuntadas a un filesystem de seguro tendre que
cambiar esa ruta si quiero cambiar el entorno del HW. Pero bueno son
maneras de ver las cosas o hasta conceptos errados :(
Tambien en temas de mantenimiento es mejor para mi la imagen dentro, en
modelos de disaster recovery puede ayudar mucho y con mirror en 2005 ni la
aplicacion tocas :) (con cluster es cierto q tampoco pero es mas cotoso
claro ;)


Saludos

[Microsoft MVP SQL Server]
www.sqlgurus.org
Buenos Aires - Argentina
"Miguel egea" wrote in message
news:%

Maxi, con todos mis respetos, eso que dices no es escalabilidad, vamos
por partes.

Separar en filegroups puede mejorar el rendimiento para tu situación,
pero como hemos discutido muchas veces, por la arquitectura de SQL las
imágenes se grabarán 2 veces una en el log y otra en los archivos de
datos, por tanto es al menos el doble de coste de disco (es más incluso).

Escalar implica que se admitan más conexiones, y metiendo las imágenes en
la base de datos jamás jamás jamás hará que sea más escalable.

¿escalar hacia arriba? Te refieres a ¿ escalabilidad vertical? confundes
el concepto, eso solo quiere decir que se puede poner una máquina más
grande.

Tenerlo en el filesystem implica quizá una pequeña sobrecarga en el
control de permisos y todo esto es cierto, pero consumirá casi seguro
menos recuros

Lo demás que dices puede afectar a la disponibilidad (nunca a la
escalabilidad) pero aún así es mucho más que discutible.

En resumen, creo que simplemente tienes un error de conceptos, eso que
describes puede ser muchas cosas ,pero nunca nunca es escalabilidad.

En cualquier caso yo no estoy ni de acuerdo ni en desacuerdo con meter
imágenes y o documentos en la BBDD. Solo que me sorprendío muchísimo que
dijeses que es más escalable. No lo es, te equivocas, has confundido el
concepto, pero :-) no pasa nada..

Saludos
Miguel Egea


"Maxi" wrote in message
news:%

Hola, claro que me ha solucionado problemas de escalabilidad, por ej de
cambiar de un server a otro y lo unico que cambie en las aplicaciones
fue la cadena de conexion, tambien me ha permitido en casos donde queria
tener mas fino el tunig separar en filegroups.
En otras palabras pude escalar hacia arriba en los servers sin mucho
esfuerzo desde el lado de las aplicaciones, me ha pasado tambien en
planes de contingencia que me ha ayudado bastante ya que hice un restore
en otro server y tenia todo funcionando de inmediado. O sea, a nivel
administrativo para mi es una ventaja y tambien me ha pasado en varios
clientes que algunos auditores me han cuestionado de tener los
documentos sin control , o sea: como se entaraba la aplicacion que en el
filesystem habia un cambio, se que es un tema muy discutido de hecho yo
antes lo ponia fuera, pero cuando espece a despejar algunas cuestiones
como que decian q era lento, etc, etc, eso jamas me ha pasado y pude ver
que SQLServer esta bien preparado para trabajar con este tipo de datos
dentro, de hecho ahora en 2005 se puede hacer lo mismo con el CLR, XML,
etc, estos reciden dentro y no hace referencia el motor a partes
externas :)


Saludos

[Microsoft MVP SQL Server]
www.sqlgurus.org
Buenos Aires - Argentina
"Miguel egea" wrote in message
news:%

¿eso te ha solucionado problemas de escalabilidad? De veras no imagino
como, meter esos objetos tiene ventajs e inconvenientes que hemos
discutido demasiadas veces, pero desde luego no mejoran en absoluto la
escalabilidad de un sistema., al menos yo no logro ver como


Saludos
Miguel Egea

"Maxi" wrote in message
news:

jjaa, sigo opinando y ejecutando lo mismo, objetos dentro de la bdd y
las imagenes tambien :) esto me ha solucionado problemas de
escalabilidad y tambien pude en algunos casos asegurar la operacion ya
que algunos audiores ISO me han traido dolores de cabeza con el otro
metodo ;)


Saludos

[Microsoft MVP SQL Server]
www.sqlgurus.org
Buenos Aires - Argentina
"Gustavo Larriera (MVP)" wrote in message
news:

SergioT wrote:

es buena idea separar la base de datos de imagenes de la de datos?
por el peso sobre todo,
influye en el desempeño de la consulta el hecho de tener imagenes
almacenadas en la BD y en otra BD

Que me sugieren para manejar las imagenes de la forma mas eficiente
y segura posible

Busca en este mismo foro, hemos discutido varias veces ese tema. Las
opiniones son diversas y todas válidas.

Personalmente, prefiero tener las imágenes almacenadas en el file
system y no en tablas de la base de datos.

El amigo Maxi opina lo contrario, si es que aún no se ha convencido
de algo mejor :-) :-) :-)


Gustavo Larriera, MVP
Solid Quality
MVP profile: http://aspnet2.com/mvp.ashx?GustavoLarriera
Blog: http://solidqualitylearning.com/blogs/glarriera/
Este mensaje se proporciona tal como es, sin garantías de ninguna
clase / This message is provided "AS IS" with no warranties expressed
or implied, and confers no rights.

Gracias Gux, yo siempre he tenido como concepto que escalabilidad era lo
segundo, de hecho en la universidad tambien me lo enseñaron asi :(, todos
los dias se aprende algo nuevo y cuando uno piensa que un concepto lo tiene
puede ser que no sea tan asi :S, es bueno aclarar estas cosas y te agradesco
la explicacion y la diferenciacion.

Entonces yo en mi post hacia referencia a adaptabilidad de mi aplicacion :)

"Gustavo Larriera (MVP)" escribió en el mensaje
de noticias:

Maxi wrote:

Bueno, quizas tengamos conceptos distintos de escalabilidad :)

Intentemos uniformizar los conceptos, somos profesionales de una
disciplina ingenieril, por tanto formal :-)

El término "escalabilidad" ha venido siendo cada vez más confuso debido a
los chicos de marketing que parecen tener una regla que dice "si no
decimos que el producto es escalable, nadie lo va a considerar" :-)

Desde el punto de vista estricto de la ingeniería de software, se define
"escalabilidad" como la habilidad que tiene un servicio de mantener su
nivel de rendimiento a pesar del crecimiento de consumidores que lo
acceden. En la definición, "servicio" y "consumidor" se usa en el sentido
más amplio de la palabra (puede ser cualquier componente que ofrezca una
funcionalidad a quien la consuma, sea un usuario, dispositivo, aplicación,
componente de hardware).

Muchos profesionales dicen que un sistema es escalable si es fácil de
adaptar o configurar a situaciones cambiantes del entorno. Este es un
concepto totalmente errado y no tiene que ver con escalabilidad. También
en ingeniería de software, esta porpiedad es "adaptabilidad" o
"configurabilidad" o "mantenibilidad". Pero no es "escalabilidad", por
cierto.

Son conceptos independientes. Un sistema puede ser escalable pero con
dificultades para configurarlo. Y a la inversa, un sistema puede ser
fácilmente configurable de un entorno a otro y sin embargo no ser
escalable (en el sentido de no soportar una carga adicional en el
servicio).

Hay un lindo artículo de Dino Espósito que recomiendo ir a leer:

"Escalabilidad, dulce escalabilidad"
http://www.microsoft.com/spanish/ms...082001.asp

Saludos!
~gux


Gustavo Larriera, MVP
Solid Quality
MVP profile: http://aspnet2.com/mvp.ashx?GustavoLarriera
Blog: http://solidqualitylearning.com/blogs/glarriera/
Este mensaje se proporciona tal como es, sin garantías de ninguna clase /
This message is provided "AS IS" with no warranties expressed or implied,
and confers no rights.

Hola Miguel, entendido, mi concepto estaba totalmente equivocado, de hecho
me lo han enseñado en la universidad asi por años :(, yo entonces lo que
queria apuntar en mi post es a Adaptabilidad de la aplicacion, en el sentido
de facilidad.
Gracias por el hilo, me han desterrado un concepto erroneo :), de todas
maneras me gusta poner las imagenes en la bdd ;-)

"Miguel egea" escribió en el mensaje de
noticias:

Maxi, no te sientas ofendido, escalabilidad no es eso, no hay más
conceptos que los que ha descrito gustavo.

Saludos
Miguel Egea

"Maxi" wrote in message
news:%

Bueno, quizas tengamos conceptos distintos de escalabilidad :), tambien
es la posibilidad de tener un server p4 y subir a un x64 tocando lo menos
posible la aplicacion, o bien si tengo una FASTI y quiero migrar a otra
FASTI que pueda escalar de HW sin cambiar casi nada en la aplicacion, si
las imagenes las tengo apuntadas a un filesystem de seguro tendre que
cambiar esa ruta si quiero cambiar el entorno del HW. Pero bueno son
maneras de ver las cosas o hasta conceptos errados :(
Tambien en temas de mantenimiento es mejor para mi la imagen dentro, en
modelos de disaster recovery puede ayudar mucho y con mirror en 2005 ni
la aplicacion tocas :) (con cluster es cierto q tampoco pero es mas
cotoso claro ;)


Saludos

[Microsoft MVP SQL Server]
www.sqlgurus.org
Buenos Aires - Argentina
"Miguel egea" wrote in message
news:%

Maxi, con todos mis respetos, eso que dices no es escalabilidad, vamos
por partes.

Separar en filegroups puede mejorar el rendimiento para tu situación,
pero como hemos discutido muchas veces, por la arquitectura de SQL las
imágenes se grabarán 2 veces una en el log y otra en los archivos de
datos, por tanto es al menos el doble de coste de disco (es más
incluso).

Escalar implica que se admitan más conexiones, y metiendo las imágenes
en la base de datos jamás jamás jamás hará que sea más escalable.

¿escalar hacia arriba? Te refieres a ¿ escalabilidad vertical? confundes
el concepto, eso solo quiere decir que se puede poner una máquina más
grande.

Tenerlo en el filesystem implica quizá una pequeña sobrecarga en el
control de permisos y todo esto es cierto, pero consumirá casi seguro
menos recuros

Lo demás que dices puede afectar a la disponibilidad (nunca a la
escalabilidad) pero aún así es mucho más que discutible.

En resumen, creo que simplemente tienes un error de conceptos, eso que
describes puede ser muchas cosas ,pero nunca nunca es escalabilidad.

En cualquier caso yo no estoy ni de acuerdo ni en desacuerdo con meter
imágenes y o documentos en la BBDD. Solo que me sorprendío muchísimo que
dijeses que es más escalable. No lo es, te equivocas, has confundido el
concepto, pero :-) no pasa nada..

Saludos
Miguel Egea


"Maxi" wrote in message
news:%

Hola, claro que me ha solucionado problemas de escalabilidad, por ej de
cambiar de un server a otro y lo unico que cambie en las aplicaciones
fue la cadena de conexion, tambien me ha permitido en casos donde
queria tener mas fino el tunig separar en filegroups.
En otras palabras pude escalar hacia arriba en los servers sin mucho
esfuerzo desde el lado de las aplicaciones, me ha pasado tambien en
planes de contingencia que me ha ayudado bastante ya que hice un
restore en otro server y tenia todo funcionando de inmediado. O sea, a
nivel administrativo para mi es una ventaja y tambien me ha pasado en
varios clientes que algunos auditores me han cuestionado de tener los
documentos sin control , o sea: como se entaraba la aplicacion que en
el filesystem habia un cambio, se que es un tema muy discutido de hecho
yo antes lo ponia fuera, pero cuando espece a despejar algunas
cuestiones como que decian q era lento, etc, etc, eso jamas me ha
pasado y pude ver que SQLServer esta bien preparado para trabajar con
este tipo de datos dentro, de hecho ahora en 2005 se puede hacer lo
mismo con el CLR, XML, etc, estos reciden dentro y no hace referencia
el motor a partes externas :)


Saludos

[Microsoft MVP SQL Server]
www.sqlgurus.org
Buenos Aires - Argentina
"Miguel egea" wrote in message
news:%

¿eso te ha solucionado problemas de escalabilidad? De veras no imagino
como, meter esos objetos tiene ventajs e inconvenientes que hemos
discutido demasiadas veces, pero desde luego no mejoran en absoluto la
escalabilidad de un sistema., al menos yo no logro ver como


Saludos
Miguel Egea

"Maxi" wrote in message
news:

jjaa, sigo opinando y ejecutando lo mismo, objetos dentro de la bdd y
las imagenes tambien :) esto me ha solucionado problemas de
escalabilidad y tambien pude en algunos casos asegurar la operacion
ya que algunos audiores ISO me han traido dolores de cabeza con el
otro metodo ;)


Saludos

[Microsoft MVP SQL Server]
www.sqlgurus.org
Buenos Aires - Argentina
"Gustavo Larriera (MVP)" wrote in message
news:

SergioT wrote:

es buena idea separar la base de datos de imagenes de la de datos?
por el peso sobre todo,
influye en el desempeño de la consulta el hecho de tener imagenes
almacenadas en la BD y en otra BD

Que me sugieren para manejar las imagenes de la forma mas eficiente
y segura posible

Busca en este mismo foro, hemos discutido varias veces ese tema. Las
opiniones son diversas y todas válidas.

Personalmente, prefiero tener las imágenes almacenadas en el file
system y no en tablas de la base de datos.

El amigo Maxi opina lo contrario, si es que aún no se ha convencido
de algo mejor :-) :-) :-)


Gustavo Larriera, MVP
Solid Quality
MVP profile: http://aspnet2.com/mvp.ashx?GustavoLarriera
Blog: http://solidqualitylearning.com/blogs/glarriera/
Este mensaje se proporciona tal como es, sin garantías de ninguna
clase / This message is provided "AS IS" with no warranties
expressed or implied, and confers no rights.