Club Delphi  
    Paypal   FTP   CCD     Buscar   Trucos   Trabajo   Foros

Retroceder   Foros Club Delphi > Principal > Varios
Registrarse FAQ Miembros Calendario Guía de estilo Buscar Temas de Hoy Marcar Foros Como Leídos

Coloboración Paypal con ClubDelphi

Respuesta
 
Herramientas Buscar en Tema Desplegado
  #1  
Antiguo 28-02-2012
Aldo Aldo is offline
Miembro
 
Registrado: ene 2004
Posts: 46
Poder: 0
Aldo Va por buen camino
Perdonad es que he querido decir decantado. Que he elegido la segunda variante que me proponias. La de guardar los ficheros fuera de la base de datos.

Un saludo
Responder Con Cita
  #2  
Antiguo 28-02-2012
Delfino Delfino is offline
Miembro
 
Registrado: jul 2003
Ubicación: Madrid
Posts: 974
Poder: 23
Delfino Va por buen camino
Uno de los puntos fuertes de Firebird es el tratamiento de los BLOB. Siempre q se pueda es recomendado guardarlos en la misma BD. Asi no hay problemas de permisos de usuario cuando se accede por red.

Dicho esto en casos extremos hacerlo guardarlos en disco parece una buena opcion. Pero hay q sincronizar los cambios entre BD y carpetas y sobre todo hay dar permisos al usuario en red sobre esta carpeta donde se van a guardar..
__________________
¿Microsoft? No, gracias..
Responder Con Cita
  #3  
Antiguo 28-02-2012
Aldo Aldo is offline
Miembro
 
Registrado: ene 2004
Posts: 46
Poder: 0
Aldo Va por buen camino
Es verdad Delfino. Pero precisamente los aspectos tenidos en cuenta par allegar a hacerlo como estoy intentándolo son:

PROS

1. Al tenerlo en un campo BLOB de la base de datos no tengo que preocuparme de la sincronización entre la base de datos y los ficheros externos a ella. Dicho en otras palabras, no tendría que preocuparme de la integridad referencial entre los registros de la tabla y los ficheros extrenos a la base de datos.

2. Esto evita tener que dar permisos a directorios en el servidor y compartir dichos directorios. Evitaría todo el tema de seguridad de windows con los directorios y los usuarios que pueden leer o escribir en dichos directorios y así que se puedan eliminar los ficheros accidentalmente o intensionadamente por algún usuario de la red

CONTRAS

1. El tamaño de la base de datos se hará muy grande y poco manejable en poco tiempo. Estamos hablando de que los ficheros pueden ocupar bastante tamaño teniendo en cuenta que son ficheros de imágenes y con mucha resolución y que no se puede degradar dicha resolución en ningún caso.

2. El hecho de tener una base da datos muy grande hace que todos los procesos en dicha base de datos sean más lentos, eso sin tener encuenta como va a manipular dicho fichero el propio windows y el Firebird.

Llegados a este punto, me decanto por la variante de guardar los ficheros externos a la base da datos.

He encontrado una forma de hacer que se graben dichos ficheros en el lado servidor. Lo he hecho con un TParam. Estoy desarrollando la idea y en cuanto lo tenga funcionando y operativo al 100 % lo subo para que veaís la solución y de paso si encontraís algún error, me ayudéis a corregirlo.

Un saludo
Responder Con Cita
  #4  
Antiguo 28-02-2012
Delfino Delfino is offline
Miembro
 
Registrado: jul 2003
Ubicación: Madrid
Posts: 974
Poder: 23
Delfino Va por buen camino
Cita:
Empezado por Aldo Ver Mensaje
CONTRAS

2. El hecho de tener una base da datos muy grande hace que todos los procesos en dicha base de datos sean más lentos, eso sin tener encuenta como va a manipular dicho fichero el propio windows y el Firebird.
Eso nunca es problema ya que Firebird guarda de manera eficiente los Blobs en paginas de datos separadas y el acceso a los otros datos no se ve afectado por haber o no Blobs en la tabla..

Lo unico es q el tiempo de Backup/Restore se hace mas largo..
__________________
¿Microsoft? No, gracias..
Responder Con Cita
  #5  
Antiguo 28-02-2012
Avatar de Casimiro Noteví
Casimiro Noteví Casimiro Noteví is online now
Merodeador
 
Registrado: sep 2004
Ubicación: En algún lugar.
Posts: 32.671
Poder: 10
Casimiro Noteví Tiene un aura espectacularCasimiro Noteví Tiene un aura espectacular
Tal y como comenta Delfino, el tamaño de la base de datos no es problema, no va a decaer el rendimiento por ese motivo, el único inconveniente es hacer un backup de un archivo tan grande, pero también tienes el inconveniente de que si tienes ficheros separados en otro directorio también tendrías que hacer otro backup aparte de los mismos.
También veo por los comentarios que has puesto, que el servidor sería windows, gran error. Debe ser linux, no sólo por seguridad, estabilidad, etc. sino también por rendimiento, que es muchísimo mayor que el que pueda ofrecer windows. Garantizado.
Usando linux tienes la ventaja del sistema avanzado de permisos, por lo que si decides usar la opción de tener los ficheros fuera de la base de datos, puedes tener un usuario con permisos para leer/escribir en ese directorio y nadie más pueda entrar en el mismo, ni a mirar.
En cuanto al tamaño de la BD, todavía no has dicho nada, pero hay casos comentados de tamaños enormes, es un tema que hemos tratado en diversas ocasiones, por ejemplo aquí.
Responder Con Cita
  #6  
Antiguo 28-02-2012
Avatar de Chris
[Chris] Chris is offline
Miembro Premium
 
Registrado: abr 2007
Ubicación: Jinotepe, Nicaragua
Posts: 1.678
Poder: 21
Chris Va por buen camino
Sinceramente yo elegiría en método de Indexar los documentos en la DB y guardarlos en el Sistema de Archivos.

Pero no has mencionado cuál sería el ciclo de vida de los documentos. Luego que los subes al servidor, los tedrás que servir de nuevo? Permitirás futuras modificaciones? Un ciclo de vida así es complicado de controlar
Código:
        --- SUBIR -->
        ^           |
        |           |
    MODIFICAR       |
        |           |
     SERVIR <--------
Para subir los documentos yo preferiría utilizar un servidor Web. Si los vas a servir y permitir modificar lo deberías hacer por un servidor WebDav.

Con respecto a lo que comenta Casimiro, sobre instalar el servidor en Linux -opinión que comparto-, no sé si DataSnap funcione sobre Linux. En mi caso, implemento los servidores de aplicaciones en LAMP o una variante de esta configuración (Python, PostgreSQL, Linux y el servidor que mejor se adapte a mis necesidades -normalmente Apache-).

Saludos!
__________________
Perfil Github - @chrramirez - Delphi Blog - Blog Web
Responder Con Cita
  #7  
Antiguo 29-02-2012
Avatar de olbeup
olbeup olbeup is offline
Miembro
 
Registrado: jul 2005
Ubicación: Santiago de la Ribera (España)
Posts: 688
Poder: 21
olbeup Va camino a la fama
Como dije al principio, la DB puede tomar un tamaño enorme por no decir bestial, como dice la frase divide y vencerás.

La idea es crear una base de datos que contenga nombre de base de datos externas que estarán relacionadas con los pacientes.

Me explico, está la base de datos principal que se llamara: HospitalXY dentro de ésta están las tablas en común (Pacientes, Medicos, Habitaciones, etc), y la base de datos que contendrán nombre de base de datos relacionada con los pacientes, que se llamará ArchivosXY.

Cita:
Ejemplo:
Tabla Pacientes, (IDPACIENTE, PACIENTE, ETC...)
Tabla ArchivosXY, (IDARCHIVO, BASEDATOS, PACIENTEID)
Cuando ingreses un paciente, el IDPACIENTE que te dará la base de datos lo añades en la base de datos (ArchivoXY)

(BASEDATOS = nombre de como se llamara la base de datos que estará relacionada con el paciente)
(PACIENTEID = paciente que has ingresado en la base de datos pacientes)

Cita:
Ejemplo:
Pacientes, (435, 'Antonio José xxxxx yyyyyy', ETC..)
ArchivoXY, (5465, 'PACI435', 435)
Cuando quieras trabajar con el paciente (Antonio José) y coger toda su documentación que se le ha realizado en el hospital, su número es el 435

A la hora de realizar las secuencias SQL's no habrá ningún problema, eje.
Código SQL [-]
...
var
  PacienteXY: String;
begin
  with adoQry do
  begin
    Close;
    SQL.Clear;

    SQL.Add('SELECT');
    SQL.Add('    IDPACIENTE');
    SQL.Add('  FROM Pacientes');
    SQL.Add('  WHERE IDPACIENTE = ' + edPaciente.Text);

    Open;

    PacienteXY := 'PACI' + FieldByName('IDPACIENTE').AsString;

    Close;
  end;

  with adoQry do
  begin
    Close;
    SQL.Clear;

    SQL.Add('SELECT');
    SQL.Add('    IDSCANNER');
    SQL.Add('    ,DESCRIPCION');
    SQL.Add('    ,FECHA');
    SQL.Add('    ,IMAGEN');
    SQL.Add('    ,OBSERVACIONES');
    SQL.Add('  FROM ' + PacienteXY + '.dbo.ScannerImagenes');

    Open;

    ...
    ...
    ...

    Close;
  end;
end;

No necesitas hacer un WHERE en la segunda adoQry por paciente ya que sabemos cual es el, pero puede hacer un WHERE por IDSCANNER para sólo mostrar uno o más de uno.

Espero haber contribuido en tu proyecto y despejar dudas

Un saludo.

P.D.: Esto está realizado en SQL SERVER
__________________
Al hacer una consulta SQL, haz que los demás te entiendan y disfruten de ella, será tú reflejo de tú saber.

Última edición por olbeup fecha: 29-02-2012 a las 09:43:34.
Responder Con Cita
Respuesta


Herramientas Buscar en Tema
Buscar en Tema:

Búsqueda Avanzada
Desplegado

Normas de Publicación
no Puedes crear nuevos temas
no Puedes responder a temas
no Puedes adjuntar archivos
no Puedes editar tus mensajes

El código vB está habilitado
Las caritas están habilitado
Código [IMG] está habilitado
Código HTML está deshabilitado
Saltar a Foro

Temas Similares
Tema Autor Foro Respuestas Último mensaje
Crear catalogo con IBSQLMonitor learning_delphi Firebird e Interbase 11 02-10-2011 11:18:28
Impresión de catálogo con imagenes quali Impresión 0 16-04-2011 16:13:02
Catalogo de Colonias mRoman Varios 10 22-03-2011 19:10:00
generar e imprimir catalogo fartycl Impresión 3 11-10-2005 17:57:35
Ventana Auxiliar O Catalogo juan-manuel-gl Conexión con bases de datos 1 09-02-2005 21:54:24


La franja horaria es GMT +2. Ahora son las 14:50:36.


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
Copyright 1996-2007 Club Delphi