|
Cita:
|
Cita:
|
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. |
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. |
Cita:
Yo cuando hablo de grandes, me refiero a más grandes... :) |
Cita:
Si son GRANDES de verdad entonces hay que estudiar bien cada caso para decidir lo que más convenga. |
¿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 |
Cita:
En mi caso uso dos bases de datos por algo que comentó Neftali: Cita:
|
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 |
Cita:
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? |
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 |
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? |
Cita:
Cita:
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). |
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. |
Me lo temía... un punto menos para guardarlo en la base de datos :p
|
¿Y qué tiene de malo?, de la otra forma también tienes que abrirlo con el programa asociado.
|
Cita:
|
Cita:
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... ;) |
Pues lo que ha dicho Neftalí, más claro no se puede :)
Además debo añadir otro factor, en mi caso, esto: Cita:
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). |
¿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 :p.
|
| La franja horaria es GMT +2. Ahora son las 16:02:51. |
Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2026, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi