¿Archivos adjuntos dentro o fuera?

[pacopenin]

Empezado por Casimiro Notevi

Bien, veo que mi propuesta va ganando adeptos
También hay que tener en cuenta que en mi caso sólo usamos servidores linux y si estuviesen en directorios distintos tendría que estar compartiéndolos por samba y sería una puerta abierta a que cualquiera pueda entrar y borrarlos o moverlos de sitio y luego... a ver quién los encuentra.
Además es una opción que funciona muy bien tanto en linux como en windows (para quien quiera seguir usando un "servidor" windows) ya que sólo es un archivo más, fácil de controlar, copiar, etc.
En fin, que eso de tener miles de ficheritos repartidos por distintos directorios y que sean accesibles por cualquiera desde fuera... no me hace ninguna ilusión.

más o menos lo que yo apuntaba, aunque la solución insinuada por Neftali lo resuelve. Lo que no me hago es idea de lo complejo que sería hacer ese "servidor de ficheros" ¿ serviría un ftp o es ya meter demasiadas capas?

[[newtron]]

Empezado por Casimiro Notevi

.... por samba ...

menos samba y más trabajar!!

[marcoszorrilla]

Pues sí, ahí veo un problema y es que mientras bailas la samba y la lambada, alguien aproveche y meta mano en los archivos....

Un Saludo.

[Casimiro Notevi]

No sé, pero a mí me parece un poco complicarse la vida con esos inventos, porque es cierto que habría que ver cada caso por separado, pero si pensamos en "lo normal", una pequeña empresa "normal y corriente" y se usa una única base de datos para todo ¿qué tamaño puede tener?, ¿1Gb, 2Gb, 3Gb?, ¿y qué?, eso no es nada, si seguro que tienen un directorio con 20 pelis de más de 1Gb cada una.
En fin, yo llevo años manejando BD de varios gigas y no he tenido ningún problema por lentitud en nada. Eso sí, una BD de 30 Gb no es tan cómoda/rápida de copiar, pero "normalmente" ninguna empresita llega a esos tamaños.

[Neftali [Germán.Estévez]]

Empezado por Casimiro Notevi

¿1Gb, 2Gb, 3Gb?, ¿y qué?, eso no es nada

Estoy contigo. Eso cabe en una llave USB.
Yo cuando hablo de grandes, me refiero a más grandes...

[Casimiro Notevi]

Empezado por Neftali

Estoy contigo. Eso cabe en una llave USB.
Yo cuando hablo de grandes, me refiero a más grandes...

Bien, entonces también estoy de acuerdo contigo
Si son GRANDES de verdad entonces hay que estudiar bien cada caso para decidir lo que más convenga.

[roman]

¿Por qué hablan de dos bases de datos? ¿No sería, en todo caso, dos tablas en la misma base? ¿Una con los datos y otra con las imágenes? Porque así no habría problemas de sincronización, se le deja al motor y ya. Mientras que con archivos aparte hay ademas que estar haciendo la doble operación de insertar/modificar/borrar el registro e insertar/modificar/borrar el archivo.

Otra cosa que no sé si ya mencionaron. Si las imágenes se guardan en la base de datos, no tenemos que preocuparnos por la nomenclatura de los archivos, que puede no ser tan sencilla.

// Saludos

[[RONPABLO]]

Empezado por roman

¿Por qué hablan de dos bases de datos? ¿No sería, en todo caso, dos tablas en la misma base? ¿Una con los datos y otra con las imágenes? Porque así no habría problemas de sincronización, se le deja al motor y ya. Mientras que con archivos aparte hay ademas que estar haciendo la doble operación de insertar/modificar/borrar el registro e insertar/modificar/borrar el archivo.

// Saludos

En mi caso uso dos bases de datos por algo que comentó Neftali:

* Mejora sustancial de las copias de seguridad (respecto a 1 Base de Datos). Seguramente la copia de la BD-Datos será más habitual, mientras que la BD-Imagenes se puede hacer con una cadencia más pequeña. El movimiento de datos en la 1ª seguramente será mucho más alto que en la segunda, de forma que podemos adecuar la periodicidad de las copias a esa relación.

Mis clientes por ejemplo suele tomar fotografías de tratamientos a sus pacientes, pero no a todos los tratamientos, solo a algunos que son bastante complejos y quieren tener bien documentados, así pues el nivel de imágenes diarias es menor al nivel de pacientes atendidos y sus demás datos tomados en el día.

[roman]

Claro. Pero supongo que esto es pensando en que por respaldo se entiende copia del archivo físico de la base. Pero dependiendo de según qué base y según qué software de respaldo, se puede más bien pensar en respaldos que excluyan una o más tablas.

Es decir, en mi caso, no suelo respaldar copiando físicamente los archivos, sino creando scripts de volcado de datos.

// Saludos

[Neftali [Germán.Estévez]]

Empezado por roman

Es decir, en mi caso, no suelo respaldar copiando físicamente los archivos, sino creando scripts de volcado de datos.

¿Eso quiere decir que no usas los comandos de Backup y Restore?
No lo he probado, pero si se trata de eso, ¿Qué puede tardar en una Base de datos de 30 o 40 GB de Datos?

[roman]

Es que ustedes, creo, están pensando sólo en Firebird o no sé. En MySQL los respaldos son siempre por script, a menos que se tenga uso exclusivo de la base y no haya problemas de concurrencia. Pero, es cierto, no sé cómo sea con bases tan grandes.

De todas formas, MySQL permite consultas entre bases, así que aún aplicaría la técnica de Casimiro dejando que el motor se encargue de la sincronización.

// Saludos

[[newtron]]

Esto es una pregunta para el amigo Casimiro.

Si metes las imágenes en la base de datos, ¿para abrirlas qué haces? ¿la grabas en el disco duro y llamas al programa correspondiente?

[Neftali [Germán.Estévez]]

Empezado por newtron

Esto es una pregunta para el amigo Casimiro.

No soy Casimiro, pero supongo que puedo... ;-)

Empezado por newtron

Si metes las imágenes en la base de datos, ¿para abrirlas qué haces? ¿la grabas en el disco duro y llamas al programa correspondiente?

Para imágenes, aun es relatívamente sencillo hacerlo directamente desde Delphi, pues los componentes de imagen pueden recibir la información directamente de los TField, pero ese es un problema que tienes si los ficheros almacenados son de otro tipo (o heterogéneos).

En mi caso es un "Archivo documental" y te puedes encontrar desde TXT, DOC, XLS, ZIP, TIFF,... Vamos, cualquier cosa. En este caso no hay otro remedio que volcar/grabar a disco en un temporal y luego abrir con la aplicación asociada al sistema (o que el usuario escoja).

[Casimiro Notevi]

Básicamente como ha dicho Neftalí.
La tabla donde almaceno los documentos, imágenes, etc. tiene un campo para indicar el tipo de fichero que es: 1.JPG, 2.BMP, 3.PDF, etc. entonces cuando es una imagen se puede abrir directamente, creo recordar que usando TStream o TFileStream (tendría que mirarlo), y para todo lo demás... se guarda en un directorio local del usuario (MiPrograma/temporal/) y se abre con el programa que tenga asociado esa extensión.

[[newtron]]

Me lo temía... un punto menos para guardarlo en la base de datos

[Casimiro Notevi]

¿Y qué tiene de malo?, de la otra forma también tienes que abrirlo con el programa asociado.

[[newtron]]

Empezado por Casimiro Notevi

¿Y qué tiene de malo?, de la otra forma también tienes que abrirlo con el programa asociado.

Si, pero si tengo ya en el disco el archivo no necesito crear un archivo temporal para abrirlo, no es que cueste mucho pero soy un poco vago

[Neftali [Germán.Estévez]]

Empezado por newtron

Si, pero si tengo ya en el disco el archivo no necesito crear un archivo temporal para abrirlo, no es que cueste mucho pero soy un poco vago

Yo aun cuando lo tengo en disco, genero un archivo temporal en un directorio. ¿Porqué?
Básicamente para que el usuario no tenga acceso al documento original.
Si abres directamente el documento original el usuario (queriendo o sin querer) puede modificarlo y guardarlo. Eso no interesa (al menos a mí no).
Suelo hacer copia en un directorio temporal de usuario y ahí que haga lo que quiera; El original se mantiene como siempre.

Ahí entran opciones de quien es el proipietario y quien tiene permiso para modificar el original y/o borrarlo, pero eso ya es otro tema...

[Casimiro Notevi]

Pues lo que ha dicho Neftalí, más claro no se puede

Además debo añadir otro factor, en mi caso, esto:

Empezado por newtron

Si, pero si tengo ya en el disco el archivo

nunca se cumple.
Porque en todos los casos, todas nuestras instalaciones son un servidor (linux) y los clientes acceden a ese servidor en busca del fichero que vayan a consultar, así que nunca está en su disco (el del usuario/cliente).

[[newtron]]

¿Pues sabéis que os digo? que me voy a dedicar a la construcción... uis... eso no que está fatal.... pues me compro un invernadero y planto pepinos .