|
|
|
Secciones
Obrar mucho, y hablar poco; que lo demás es de loco.
Barrapunto © 1999-2007. Contenido disponible bajo licencia Creative Commons Reconocimiento 2.5
Aviso legal
Barrapunto © 1999-2007. Contenido disponible bajo licencia Creative Commons Reconocimiento 2.5
Aviso legal
Buena pregunta
(Puntos:-1, FueraDeTema)( http://barrapunto.com/ )
¿Es mejor cagar meando o hacerlo por etapas?
--
~ mírale, ahí va... con su mujer y mi hijo... ~
Buena pregunta...
(Puntos:-1, Provocacion)( http://barrapunto.com/ )
¿Es mejor cagar meando o hacerlo por etapas?
--
~ mírale, ahí va... con su mujer y mi hijo... ~
No se la respuesta pero ...
(Puntos:-1, FueraDeTema)( http://barrapunto.com/ )
Te responderan que eres un intruso, te diran que si te haces esa pregunta es que no merece estar en el sitio de trabajo donde estas. Te diran que dejes que alguien que sepa lo que hace ocupe tu lugar de trabajo y tu te vayas a otro tipo de trabajo.
Tambien te diran que con un colegio de informaticos esto no pasaria y te diran preguntaran si tienes titulo universitario y si es asi que donde lo compraste.
Si tienes suerte alguien te contestara, pero la tonica general no tengo duda que sera esta.
Preguntar esta mal visto, se malinterpreta como un signo de debilidad. Y aqui, en barrapunto, "somos" expertos en estrujar esa supuesta debilidad sacando todas nuestras neuras a relucir.
Saludos y suerte, compañero.
Utiliza base de datos
(Puntos:5, Interesante)( http://www.baidez.net/ )
- Si la cantidad de ficheros a almacenar es muy grande y la capacidad no importa yo los pondría como campo en la BD. En el momento que están insertados tienes las mismas ventajas que el resto de información que almacenes en la DB, vease tratamiento de consultas, seguridad de acceso según usuarios, coherencia, etc. Por no comentar que lo tienes centralizado sin importante donde reside la información o si se te corrompe el sistema de ficheros (el SGDB te hace hasta el backup).
- En caso de que el número sea pequeño y el acceso lo quieras más primitivo aprovecha el sistema de ficheros.
Yo, personalmente, en cosas muy serias y con grandes cantidades de ficheros lo pondría con DB, sino no.
If you don't know where you are going, you will probably end up somewhere else.
Laurence J. Peter
Re:Utiliza base de datos
(Puntos:5, Interesante)( http://barrapunto.com/ )
mejor en el sistema de ficheros
(Puntos:4, Informativo)( Última bitácora: Domingo, 04 Septiembre de 2005, 12:57h )
No creo que sea una buena idea sobrecargar la base de datos haciendo que se ocupe tambien de los ficheros, ya que esto supone un importante volumen de datos que manejar.
PISO Pontevedra con Garaje. Rias Baixas. Sanxenxo. Centrico. Playa. [pisopontevedra.com.es]
Los ficheros, en sistemas de ficheros
(Puntos:3, Interesante)Si los ficheros pueden ser cualquier cosa, y la base de datos no va a tratar con el contenido del fichero propiamente dicho, creo absurdo usar blobs, entre otras cosas, porque ocuparán más espacio en el disco duro sin añadir información. Además el acceso será mucho más lento.
De todas formas, como en todo, depende. Depende del tratamiento, de la aplicación en si, de la tecnología empleada, etc.
Por ejemplo, si no recuerdo mal, el Oracle Forms (es decir, lo que haces con el Oracle Developer) guarda los ficheros en blobs, pero es por la filosofía de Oracle "todo es la base de datos".
Una ventaja de usar ficheros normales y corrientes es que puedes poner accesos alternativos sin necesidad de usar la aplicación cliente de la base de datos. Puedes hacer que se pueda llegar a los ficheros desde directamente ftp, NFS, SMB, webdav, etc. sin la intervención de la base de datos.
Re:Los ficheros, en sistemas de ficheros
(Puntos:4, Informativo)( http://barrapunto.com/ )
1 - Si utilizas una herramienta de Backup para Oracle es dificil incluir la ruta donde dejes los ficheros.
2 - En caso de corrupción de la partición no tienes las herramientas de recuperación que puede tener un gestor de Base de Datos como Oracle.
Si guardas la información en la BD como un campo LOB puedes separarlos en otro tablespace diferente para evitar problemas en el tablespace de datos. Los ficheros también se pueden enviar directamente sin necesidad de realizar un ftp o exportar directorios por NFS o SMB. En el cliente puedes recuperar el fichero mediante una SELECT a dicho campo utilizando las estructuras correspondientes el PL/SQL o mediante ProC o su equivalente en Java.
Creo que Oracle también se encarga de realizar la compresión de dichos campo LOB.
¿Como lo hace los sistemas documentales existentes, tal como Documentum? Guardan los ficheros en campos LOB de la BD Oracle o similar.
Mi opinión
(Puntos:2, Informativo)Sin duda no lo almacenes en la base de datos ...
(Puntos:3, Informativo)( http://www.loeda.es/ | Última bitácora: Sábado, 04 Agosto de 2012, 14:10h )
En su tiempo diseñe una base de datos que almacena fotos de placas, corria sobre MSSQL Server y las placas se almacenan en el base de datos, con el tiempo (apenas 90 dias) la base tenia ya 2G de tamaño y las copias eran una locura, ademas menear este tipo de campos (los que contienen la imagen) son siempre muy problematicos.
Recomendación, almacenalos en ficheros, y en la base de datos una refencia al fichero, es mucho mas facil
La Zapatilla Azul [loeda.es]
Et in terra pax hominibus bonæ volu
Sin duda Depende....
(Puntos:4, Interesante)Depende del SGBD y del Servidor
(Puntos:2, Informativo)Depende de muchas cosas...
(Puntos:2)Por ejemplo, si se tratase de Oracle (a partir de la versión 9i), si los ficheros fuesen documentos XML, si hubiese muchos y de cualquier tamaño y si pretendieses luego acceder a la información que contienen de manera eficiente y directamente a partir de consultas SQL de la misma forma que si se tratase de datos en tablas (es decir, internamente indexados), entonces en ese caso sin duda alguna, utiliza las funcionalidades que para ello te ofrece Oracle y su potentísimo soporte para XML. Todo serán ventajas.
Sin embargo, esto es sólo un ejemplo muy específico. Para cualquier otra necesidad, hay que estudiar a fondo los pros y los contras de tomar una u otra decisión y, sobre todo, tener muy claro lo que se pretende y cuánto se está dispuesto a pagar (en términos económicos y no económicos, como rapidez de acceso, optimización del espacio...).
En fin, me parece que a no ser que tu caso sea como el que expongo, no te habré ayudado demasiado, pero mira que si lo fuese... ;-)
Un saludo, ¡y suerte!
Yo soy de los de base de datos
(Puntos:3, Interesante)El volumen es mas o menos importante, unas 20000 mensuales y bueno, me parece una chapuza informática meter semejante número de ficheros en un sistema de archivos (y no es güindon, no señor).
Meter las imagenes en la base de datos nos aporta otra serie de ventajas, por ejemplo, si se conecta un cliente remoto via inet, la misma aplicación recibirá las imagenes como si fuese local, entre otras cosas.
La base de datos usada es PostgreSQL, y sobre el asunto que comentan por ahí del tamaño de las copias, para copiar solo los datos, pg_dump, sin opcion -b, si quieres los blob, con -b, de todas maneras si hay que hacer un backup de las imágenes, también ocuparán lo suyo aunque sean archivos.
Pero como siempre, para gustos, los colores
Re:va a ser gigante esa base!!!
(Puntos:4, Inspirado)( http://mcpolu.blogspot.com/ | Última bitácora: Miércoles, 05 Marzo de 2014, 00:04h )
Me pongo un vestidito rosa y unas gafas redondas cual azafata del "un dos tres" para decir, calculadora en mano, que:
"700kb cada imagen por 20.000 imágenes al mes suponen una base de datos con un crecimiento de... ¡14 Terabytes mensuales! que multiplicados por 12 meses que tiene un año suponen... ¡1´7 Petabytes anuales! ¡Sólo en imágenes! ¡Sin contar las tablas auxiliares y los índices sobre las mismas!"
Me rasgo el vestidito rosa y me quedo en bolas para decirte que como metas eso en posgreSQL la hostia que te vas a dar va a ser escuchada desde la estrella Vega. Si me cuentas que el posgre lo usas para los campos índice y que las imágenes van a un IXOS [ixos.com] me lo creo. Pero si me cuentas que vas a meter una BBDD de ese tamaño en posgre, sólo me queda preguntarte por la fecha del pase a producción para ir encargando la corona de flores.
En España la mejor manera de guardar un secreto es escribir un libro.
se almacena la URI.
(Puntos:2)( Última bitácora: Lunes, 07 Febrero de 2005, 03:05h )
En la base de datos se debe guardar la URI del archivo en cuestión, de la forma mas independiente de la plataforma que sea posible.
Igual que las imagenes
(Puntos:0)Luego cambié a un campo VARCHAR en donde guardaba la dirección del archivo .JPG, las imagenes las deposite en un servidor de archivos. Pero aparecieron los problemas:
1. Debia tener seguridad en la base de datos y en el servidor de archivos (cualquiera podía ver el directorio compartido de imagenes),
2. Un buen dia decidieron cambiarle el nombre de la maquina en la red y se perdieron todas las referencias (antes se llamaba \\saturno y despues \\ventas),
3. Otro dia la base de datos estaba bien pero el servidor de archivos estaba caido (los usuarios veían un recuadro en blanco en cada registro)
4. Si un gracioso desde SQL borra un regisro la imagen sigue allí, es dificil sincronizar.
5. Tu software cliente debe dialogar no solo con la base de datos sino programarle varias rutinas para que envíe o reciba datos de un servidor de archivos o un servidor de paginas web.
YO SOY DE SISTEMA DE FICHEROS
(Puntos:0)NO LOS METAS DENTRO
(Puntos:0)si no fuera por lo de la seguridad
(Puntos:0)yo es que veo lo de meter el archivo en bdd bastante bastante desaconsejable por el tamaño de bdd que ello supondría.
si necesitase lo de la seguridad, iría de cabeza a buscar la forma de proteger los ficheros sin meterlos en la bdd.
Prefiero el sistema de archivos
(Puntos:2, Interesante)Personalmente me inclino por guardar los archivos en el disco duro teniendo las debidas relaciones en la BD....lo digo porque hace poco termine una aplicacion que se encarga de almacenar un historial de imagenes gigantesco, y era necesario efectuar copias de seguridad constantemente...y hacerlas basados en la BD resultaba muy tedioso para cliente, asi que las imagenes se iban organizando en carpetas segun la capacidad del disco en donde se fueran a quemar de manera automatica.
De esta forma resulta mucho mas facil realizar las copias, sin embargo era necesario que los archivos se cifraran y que solo a traves de la aplicacion se pudiera tener acceso a los mismos.
¡Ojalá fueran todas las preguntas tan sencillas!
(Puntos:0)En el sistema de... ¡ficheros!
"¿Cuándo es mejor en un directorio?"
En la práctica totalidad de los casos.
"¿Cuando es mejor en una base de datos?"
En un único caso:
Cuando los desarrolladores y/o los administradores del sistema sean unos incompetentes.
Habrá (hay) bastante gente, incluso que se llamen a sí mismos "desarrollador experto", "senior developer", "analista profesional" y cosas semejantes que opinen que es mejor meter ficheros en la base de datos. Ver caso anterior.
Robots de almacenamiento masivo
(Puntos:3, Redundante)( http://mcpolu.blogspot.com/ | Última bitácora: Miércoles, 05 Marzo de 2014, 00:04h )
Bueno, ya te han dado algunas respuestas y no tiene mucho sentido que vuelva a escribir lo mismo que han escrito los demás. Sin embargo, nadie ha comentado nada de almacenamiento masivo, así que aun hay espacio para una pequeña aportación:
No creo que se trate de un sistema grande porque si lo fuese no se lo darían a alguien que pregunta a Barrapunto (lo siento, no he podido resistirme) y no creo que se trate de un sistema pequeño porque ni siquiera te plantearías meter los archivos en la BBDD.
En resumen, que mi respuesta es que metas los archivos en la BBDD, que así queda el sistema más """aerodinámico""" :P
En España la mejor manera de guardar un secreto es escribir un libro.
Meter o no meter ;)
(Puntos:2)( http://www.jmcresearch.com/ )
Si lo que quieres es explotar el contenido de los archivos (hacer búsquedas dentro de ellos y pirulas variadas) puedes preguntarte a ti mismo si te merece precachear esa información en la propia base de datos (por ejemplo, con una estrategia de acceso que te permita generar un "resumen" y almacenarlo en la base de datos).
Si lo que te pasa es que quieres ser comodón y ahorrarte un poco de programación, acuérdate que si el cliente y el servidor de base de datos se conectan por una linea de baja velocidad, acabarás precacheando en el cliente esos mismos ficheros para que la cosa vaya bien (imagina un select id,image limit 10 con sizeof(images) ~1M, sin cursores)
<your quote here> --Bjarne Stroustrup
Cuestión de requisitos, maquinaria y gustos :)
(Puntos:1)( Última bitácora: Martes, 31 Octubre de 2006, 18:26h )
Bueno, al final he decidido almacenar las imágenes porque son pequeñas (ocupan menos de 50 KBs cada una), porque de vez en cuando se borrarán ya que son para hacer debug y aunque para cada imágen debo almacenarla hasta saber si se ha introducido bien lo que ponía en ella (si lo hace mal, debo pasarla a otra tabla), es decir, estoy generando muchas imágenes pequeñas; creo que es la mejor solución para no depender de directorios ni rutas ni similares que luego al pasarlo a otro sitio tengo que andar preocupándome de guardar.
Otra cosa es si tu sistema está todo el día usando dichas imágenes, la carga sobre la BD será alta si se almacenan en ésta.
Así que yo creo que todo depende de los requisitos de la aplicación, de la maquinaria disponible (sería un suicidio poner un MySQL a manejar exclusivamente imágenes en una máquina poco potente) y también es cosa de gustos personales.
Puedes también hacer uso de una opción mixta, más bien hacer uso de cache, y dejar en un directorio las imágenes que se usan con más frecuencia; es decir, las imágenes estarían en la BD, pero las más usadas estarían en disco.
Y si te decantas por dejarlo en un directorio, pues no tienes muchos problemas; hay muchas formas de guardar la referencia a la imágen en la BD (aunque yo me decantaría por la nueva forma que tiene Mambo 4.5.3 de obtener los ficheros de disco :P )
Venga un saludo
Mételo en la BD
(Puntos:0)Digan lo que digan algunos imbéciles que encima se las dan de listos, tener una BD con referencias a un sistema de ficheros es como tener dos Bases de Datos distintas para una misma cosa. Absurdo, poco elegante, y problemático. Ya lo han mencionado, pero lo repito: si quieres hacer copias de seguridad y usas ficheros tendrás que hacer dos por el precio de una.
Además, si quieres instalar la aplicación en sistemas multiusuario de terceras partes -proveedores de hosting, por ejemplo- aparte de pedir una cuenta en la BD que utilices tendrás que pedir también una cuenta para acceder al disco duro con ingente espacio para meter las imágenes. Muchos proveedores de hosting facturan como dos servicios distintos ambas cosas.
Otra ventaja más de meterlo todo en la BD es la portabilidad: podrás instalar la BD completa en cualquier sistema que soporte ese motor de BD sin mayores complicaciones, mientras que si tienes que acceder al sistema de ficheros tendrás que prevenir las particularidades de cada uno (bloqueo de archivos, gestión de permisos, e incluso el formato de los nombres de archivo permitidos).
Mi pobre experiencia
(Puntos:2, Interesante)Base de Datos: Firebird sobre linux
El sistema mediante un scripts en php coge el fax recibido por hylafax, le extrae los metadatos, le asigna un código y lo guarda (en formato tiff) en el servidor en un campo blob.
La base de datos tiene ahora 442 Mb, el primer fax lo recibio el día 2002-09-25 10:15:31.0000, y tiene almacenados 7611 faxes.
Todo va perfecto, se facilita la catalogación y redistribución de los faxes pero lo cierto es que en una pyme no se pueden pedir grandes inversiones en infraestructura informática. Con este tamaño tarda mucho a la hora de hacer las copias de seguridad, y hay que tenerlo en una base de datos independiente de la del ERP, y se pierde la integridad referencial con respecto a las tablas de remitentes (proveedores, clientes) y de trabajadores para redistribución.
Luego para hacer la copia de seguridad hay que copiar un archivo de 409 Megas (el backup, no la base de datos original) que cambia todos los días.
Cuando pasen otros dos años seguramente esté en un nivel intolerable y haya que tomar alguna decisión.
Ahora cuando tengo un entorno intranet controlado pongo los enlaces al servidor de archivos, siempre relativos, nunca almaceno caminos completos.
Por ejemplo los archivos de pedidos, almaceno la ruta general ("\\master\ventas\pedidos") en una tabla de rutas y luego monto el path completo añadiendo la referencia del pedido. Esto me facilita la movilidad de los archivos aunque si cambias el número de pedido tienes un problema, que tampoco es tal con menos de 10 líneas de código, pero que por perro no he contemplado. Ten en cuenta que este sistema no permite el acceso remoto y solo es aplicable a la intranet, aunque esto sería facilmente salvable, al menos en linux, usando fish:// y un servidor ssh en la máquina servidora.
Pero en el caso de los faxes creo que no usaría este modelo ya que solo me permite un control de acceso rudimentario (a través de samba). Ahora montaría un servidor TCP con un protocolo de no más de 10 comandos (lo he mirado en java por la multiplataforma, manejo de hilos, etc) que autentificase contra los usuarios de firebird, determinase sus privilegios de faxmaster, e incluso restringiera a los usuarios no faxmaster en función de la distribución que hagan los faxmaster de los distintos faxes. En el cliente sería cuestión de montar la contrapartida cliente tcp y de sincronizar las gestión de los faxes en las dos direcciones: base de datos con los metadatos, clasificación y distribución y el servidor tcp de manejo de los ficheros. Incluso un sencillo scripts en php o python (por no sobrecargar con la VM de java) podría realizar una sencilla sincronización entre base de datos y archivos para eliminar basura periódicamente, y más en mi caso que pretendo gestionar también los faxes enviados con almacenamiento automático de reportes de envío, todo gracias a las bondades de hylafax, samba, php, linux,
La verdad es que montarlo sobre otro sistema propietario sería horrible, por lo pronto mediante samba guardo los fax a enviar con un simple scripts que se lanza cuando imprimes en una pseudo-impresora, y no alcanzo a saber como hacer lo mismo con el servidor CIFS de microsoft.
Bueno, espero que la batallita te haya dado al menos ideas, mi síntesis es que "guardarlo en la base de datos si vas a guardar muchos archivos es la forma fácil pero no creo que sea la mejor".
Yo al contrario de otra persona que te respondio antes, solo lo uso para ocasiones en que no se vayan a almacenar muchos archivos y por ello no merezca la pena complicar el diseño de la estructura servidora y la programación del cliente.
Esto te permitirá también una mayor independencia con respecto a tu SGBD, si la incluyes en el servidor y crece mucho (como parece tu caso que además tiene unas necesidades muy concretas), con el tiempo tendrás que tirar de sistemas SGBD como Oracle y todo por no haber curra
Los ficheros en el sistema de ficheros
(Puntos:2)Esta pregunta nos la hemos planteado muchos. En mi experiencia es mejor guardar los ficheros en el sitio que le corresponde, siempre que no tengas que tratar los contenidos como dicen más arriba.
Meterlos en un BLOB sólo sobrecarga la BBDD, entorpece las consultas y el acceso a los mismos es muy lento.
Una vez cometí el error de insertar en una tabla las fotos de los usuarios. Era un MySQL 3.23. Cuando la tabla llegó a 70Mb el acceso a la base de datos era lentiiiiiiiiiiisimo, y toda la aplicación se vió afectada. Consecuencia: Me tocó migrar esa tabla a ficheros normales y modificar la aplicación (pérdida de tiempo considerable).
Espero haberte ayudado. Saludos.
RE: Superdotados de barrapunto
(Puntos:0)Cuidado
(Puntos:0)Alguien puede dar datos/ejemplos mas concretos?
(Puntos:0)Ya se que M$ Access es un mal ejemplo... ;-) pero desde entonces lo pienso 2 veces antes de meter según que en una BD
Otro ejemplo: Supongamos que quiero hacer una BD para catalogar todos mis CD's/DVD's, y meter en la BD las .iso de cada uno...
Podría hacerlo con M$ SQLServer? MySQL? PostgresSQL? con Oracle? con M$ Access seguro que no...
cuantos cabrían en la realidad? alguien lo ha probado?
cuanto tardaría en introducir / sacar cada .iso localmente? lo mismo que copiar la .iso entre dos carpetas?
y remotamente el rendimiento seria el mismo que usando ftp, http, rsync, scp, smb? y como lo haría? via http con un php/perl/cgi que se encargue de meterlo / sacarlo en la BD (que pasa con los timeouts del http y del php)? o un cliente de BD? o un cliente programado apropósito...
y el espacio real ocupado en disco? (los sistemas de archivos pierden espacio en cada fichero en los clusters incompletos.)
cuantos segundos tarda una determinada consulta sin ninguna .iso en la BD y una con x .iso's?
Meterlo todo en la BD queda muy bonito y estructurado, pero a la practica lo veo mas fácil de programar y con menos probabilidad de fallo si lo meto en el sistema de ficheros.
Como te diría Linux...
(Puntos:3, Interesante)( http://barrapunto.com/ )
¿Y no puede hacerse de las dos maneras?
Me explico.
Ya que sabes que es un punto conflictivo hazlo de manera que sea facil cambiar de un modelo a otro.
Por ejemplo: Usa una tabla en la que tengas la ruta al fichero y el campo binario del fichero y deja a null lo que no uses. Así cualquier referencia al fichero tendrá que pasar por esa tabla.
El día que descubras que la base de datos (o el sistema de ficheros) no te sirve, pues haces un proceso que los cambie de sitio y punto.
Depende, pero normalmente en BD
(Puntos:1)Que te interese guardarlos en BD o sistema de ficheros depende de muchas cosas... pero casi siempre es mejor hacerlo en BD.
Asumo que "guardar en filesystem" significa tener una tabla de la BD con un path que apunta al fichero, estando este guardado en disco, ya que guardar ficheros "a lo bruto" rara vez sirve para nada.
Ventajas de guardarlos en BD:
- La BD te gestiona la seguridad de forma coherente con el resto de la información, en el filesystem tendrías tu que preocuparte de mantener coherentes las ACL con la seguridad que hayan introducido en BD.
- El acceso es transaccional: si a mita de escritura se va todo al garete, rollback y aquí no ha pasado nada. En filesystem... no he visto nunca a NADIE implementar el acceso como dios manda, en caso de error el fichero queda corrupto y no hay forma de volver atrás. Pero es que hacerlo bien es un suplicio.
- Los backups son más sencillos.
- Puedes usar sistemas de replicación para tener tolerancia a fallos manteniendo la coherencia entre la BD y los ficheros. Si los ficheros van por libre, normalmente ni tolerancia a fallos ni nada.
- Te despreocupas de gestionar los path (¿qué pasa si necesitas más espacio y quieres guardar más ficheros en otro disco?)
Desventajas de guardarlos en BD:
- Si los ficheros son para que los use una aplicación externa (por ejemplo, documentos de word), tendrás que copiarlos a un fichero temporal local antes de abrirlos, y eso consume tiempo (ej: ficheros de video).
- A veces los ficheros no tienen significado aislados, sino que forman una estructura (por ejemplo, los ficheros .IFO y .VOB de un DVD). Hay que guardar esa estructura en la BD, y ahí empiezan los líos.
Resumiendo: como primer intento, guardalos en BD. Si tienes problemas, entonces te comes el tarro para guardarlos en filesystem, pero para hacerlo bien... agarrate que vienen curvas.
un ejemplo
(Puntos:0)Me sorprende que aún nadie haya hecho referencia al ejemplo más notorio que tenemos a mano.
Flickr [flickr.com], almacena las imagenes en el sistema de archivos.
Aunque a la hora de la verdad creo que lo que más importa es que se va a hacer con esos datos como serán los accesos.
mis experiencias
(Puntos:1)Gracias por todos las sugerencias recibidas. Me queda claro.. me queda claro que existen dos grandes equipos enfrentados con este tema.
En mi experiecia: he participado en 2 grandes proyectos de software que necesitaban almacenar ficheros en el disco duro. En los 2 casos lo hemos resuelto almacenando los ficheros en el sistema de ficheros.
Esto nos ha causado algunos problemas, que ya han sido comentado arriba:
Nunca he tenido experiencia almacenando los ficheros en la BD, pero, gracias a vuestros comentarios puedo hacerme una idea de a lo que me voy a enfrentar.
Gracias.
Mi opinión.
(Puntos:2)( http://www.cientifico.net/ | Última bitácora: Martes, 22 Junio de 2004, 13:46h )
Bueno muchacho. Hata donde yo sé, depende mucho de varios factores:
Creo que lo que mejor puedes hacer (Me imagino que accedes a traves de tomcat, o un servidor web), es implementarlo de las dos maneras (unas 20 lineas de diferencia (por lo menos para las pruebas (prueba solo lo que más se valla a repetir, como la consulta, ya que la adición suele ser menor)). Tienes por ejemplo tu archivo index1 e index2. Te buscas en internet un puteador de webs (no se como se llama ahora mismo). Es un programilla que pide a tu server desde localhost, unas 1000 consultas ( o las que le especifiques), y te dice tiempo de respuesta de la página, paginas erroneas (errores 550), etc... Si te lo montas bien tambien puedes monitorizar la cpu y la ram.
Esto en cuanto rendimiento.
Espacio, no creo que ocupará el mismo o similar.
Comodidad. Almacenando en BLOB, solo tienes que hacer copia de seguridad de la base de datos. De la otra manera no.
Seguridad. Si lo almacenas en la base de datos a mi entender es mas seguro (entendiendo como seguro que hay menos probabilidades de meter la pata). Si lo almacenas en el disco duro, tienes que cuidarte de permisos y demas rollos.
Bueno guapeton, nos vemos.
Besos.