Columna de ruta

Hola Guille, muy bueno que compartas estas cosas. Yo he trabajado con datos
fuera de la bdd por muchos años porque siempre pense que era lo mejor, hasta
que una persona me demostro que SQL esta mas que preparado para manejar los
datos adentro y con una performance excelente. Que sucede en la mayoria de
los casos, hay que ser muy prolijo en lo que respecta a diseño y la
arquitectura de la aplicacion, pero hoy dia conozco sistemas desarrollados
para SQL documentales que tienen una peformance muy buena de verdad. Claro
hay que ser bien medidos y ver como poner las cosas no, no es cuestion de
poner archivos de 15MB sino vas a necesitar un gran disco.
Pero hoy dia yo le encuentro muchas ventajas en tener las imagenes dentro y
como te mencione es cuestion de pensar bien los diseños cosa que no es facil
claro pero no imposible.
Un abrazo


Salu2
Maxi [MVP SQL SERVER]
www.sqlgurus.org


"Guillermo Roldán" escribió en el
mensaje news:%

En una ocasión, me encontré con una tabla que utilizaba un campo text en
vez
de un campo varchar. Esto era debido a una migración de una base de datos
Access, y claro, como en Access sólo puedes guardar hasta 255 caracteres,
pues si quieres más tienes los famosos campos "Memos", que al final, al
pasarlos a SQL Server en vez de pasarse como varchar(2000) por ejemplo, se
pasan como campos text... aunque el más grande (len(campo)) no supere los
1000 caracteres.

Con 10 registros no se nota. Con 10.000 tampoco. Pero cuando empezamos a
hablar de varios cientos de miles o de algunos millones, teniendo en
cuenta
que no todas las aplicaciones están indexadas correctamente (en ocasiones,
algo que como DBAs no podemos cambiar por ser aplicaciones de terceros, o
de
un departamento un poco más chic de la misma empresa), se nota la
diferencia
en el rendimiento, y es que los campos grandes se almacenan fuera de las
páginas de datos de la propia tabla como tal.

En su día, me encontré con esto en un cliente, y se notó el rendimiento al
cambiar de text a varchar, creeme. Creo que era una tabla con cinco
millones
de registros, más o menos.

Por otro lado, en el cliente en el que estoy ahora, tienen una aplicación
de
gestión documental, que almacena la entrada de todos los documentos. En
consecuencia, tenemos 52 servidores SQL Server, más o menos, uno en cada
provincia de España, cada uno de los cuales almacena en su motor
documentos
TIF y además datos. Esto da algunos pequeños problemas, como:
- Las copias del Log diarias, aún haciéndolas cada tres horas, se llegan a
solapar !!
- El volumen de datos de cada provincia sólo para esta aplicación (que
lleva poco tiempo) son 5GB, cuando sino, hablaríamos de una pequeña base
de
datos de 200 ó 300 MB como mucho, que te funcionaría bien incluso con
MSDE,
y que resulta mucho más manejable (ej: tiempo de un backup Full y de un
restore).
- Los más cojonudo, es que los programadores son unos hachas: Además de
cargar las imágenes en SQL Server las guardan en el propio sistema de
archivos del servidor... ¿?¿? Al principio me resultó un poco traumático,
pero luego uno se acostumbra... ;-)
- Los programadores se están encontrando con problemas de tiempos de
respuesta y bloqueos. No voy a discutir que si programación se podría
mejorar (no utilizan procedimientos almacenados y la indexación se podría
optimizar, por poner dos ejemplo triviales), pero los problemas que
tienen,
si estuvieran jugando con las imágenes fuera de SQL Server, nos les habría
ocurrido.

Yo personalmente también le encuentro ventajas a almacenar documentos en
la
base de datos, pero prefiero a consejar que en principio no se haga, salvo
que se tengan las cosas muy claras... como la seguridad, primero cierra
todos los puertos, y luego ver abriendo los puertos que realmente hagan
falta.

En una aplicación de comercio electrónico que tengo, por dar un ejemplo,
cada Artículo tiene una foto (o ninguna o varios, vamos). La foto, la subo
con un upload desde aspnet, y la guardo en el servidor en una carpeta del
IIS. Va muy bien, y la base de datos es muy rápida. Sin embargo, cuando
quiero mover un artículo de una Familia o de un Catálogo a otro, me
encuentro que cambia la ruta o el nombre del fichero imagen en el
servidor,
lo que me genera trabajo extra: desarrollar los procedimientos de la base
de
datos, y las clases .Net que muevan los ficheros. Es decir, hay que
gestionar el alta, actualización y eliminación de los ficheros además de
en
la Base de Datos, y esto es más laborioso. Sin embargo, la base de datos
va
como un tiro, el registro de transacciones no sufre cuando hay cargas
masivas, y es muy ligera. En esta aplicación, también hay triggers de
auditoría / control de cambios, lo cual me supone que cada vez que cambia
el
precio de un artículo (hay actualizaciones diarias de miles de artículos),
saltan los triggers de auditoría, los cuales los tendría que modificar
para
que no me dupliquen el campo documento "por que sí" pues esto inflaría la
base de datos de mala manera. Algo solventable, pero a fin de cuentas, hay
q
ue "ir sumando" ventajas e inconvenientes antes de declinarse por una
opción
u otra.

Como todo en esta vida, hay que buscar un equilibrio, pero siendo egoista,
para la base de datos siempre será mejor que lo guardemos fuera... aunque
en
ocasiones, por las circunstancias lo guardemos dentro (el ejemplo de
Sharepoint es muy bueno, en este caso).

Esto son cosas que me han ocurrido, y me dan pie a pensar así, pero simpre
está bien conocer el punto de vista y los escenarios de los demás, está
claro.

En fin, saludos, que tengo que salir al curro "raudo y veloz"
Guille

"Maxi [MVP]" escribió en el mensaje
news:

Hola Guille,

> Siempre que puedas, es aconsejable guardar los documentos fuera del SQL
> Server, no sólo por rendimiento

Esto no lo comparto, en que te basas en decir que hay problemas de
rendimiento? y ademas que otros problemas mas le ves?


Salu2
-
[MVP] SQL Server
Orador para Culminis Latam
www.sqlgurus.org

MSN:

"Guillermo Roldán" escribió en el
mensaje news:
> Hola Pablo,
>
> Siempre que puedas, es aconsejable guardar los documentos fuera del SQL
> Server, no sólo por rendimiento. Para ello, si utilizas ASP puedes

emplear

> un componente de terceros como ASPupload, o bien, si utilizas ASPNet,
> te
> vale con su propio modelo de objetos (por cierto, la hostia el ASPNet
> ese...). Esto te permite desde tu formulario, especificar un fichero de

tu

> disco, y subirlo a una carpeta de tu webserver, para luego
> referenciarlo
> por
> un hipervínculo, por ponerte un ejemplo. Yo lo hago con mis

aplicaciones,

> y
> funciona muy bien.
>
> No obstante, si te interesa especialmente guardar un documento en las
> tablas
> de SQL Server, esto se puede hacer. Más aún, hay productos de Microsoft
> como
> SharePoint (tanto Portal como Team Services) que almacenan hasta las
> páginas
> web en el propio SQL Server... así como documentos de word, etc. Tiene

una

> cosa muy buena, y es que con hacer el backup de SQL Server... puedes
> dormir
> tranquilo. Como mucho, reinstalas sharepoint en otra máquina, y le
> dices
> que
> se conecte a tu BBDD SQL, y lo pilla todo de ahí: páginas aspx, htm,
> documentos office, pdfs, etc. Maravilloso el sharepoint ese... (sobre

todo

> porque la instalación de team services dura menos que un estornudo).
>
> De cualquier modo, te anexo un trozo de código visual basic utilizando

ado

> para guardar un documento en sql server:
>
> Public Sub SubirArchivo(Rs As ADODB.Recordset, ByVal strRutaArchivo As
> String)
> Dim Stm As ADODB.Stream
> Set Stm = New ADODB.Stream
> With Stm
> .Type = adTypeBinary
> .Open
> .LoadFromFile strRutaArchivo
> Rs.AddNew
> Rs.Fields("NombreCampoBLOB").Value = .Read
> Rs.Update
> .Close
> End With
> Set Stm = Nothing
> End Sub
>
> Espero que con esto, y un poquito de Google, puedas solucionar tu
> problema.
>
> Saludos,
> Guillermo Roldán
>
> "Pablo Paredes" escribió en el
> mensaje news:
>> Saludos:
>>
>> Bueno realizo una pagina en asp.
>>
>> tengo un formulario el cual guarda datos en la bd. hay una caja de

texto

> en
>> la cual coloco un nombre por ej: ARCHIVO.DOC, esto se guarda solamente
> como
>> texto. Por otro lado guardo el documento en una carpeta y el archivo

con

> el
>> mismo nombre que lo guarde en texto osea ARCHIVO.DOC
>>
>> Bueno el asunto es que no e encontrado algun S_P o algun codigo para
> enrutar
>> a mi documento y luego mostrarlo en una tabla en mi web como un
> hipervinculo,
>> e revisado otros post pero en concreto no resultan. poseo sql server
>> 2000.
>> Porfavor algun codigo o formula concreta si conocen y muchas gracias

por

> su
>> tiempo.
>
>