Catálogo de Documentos en el Servidor

[Delfino]

Empezado por Aldo

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..

[Casimiro Noteví]

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í.

[[Chris]]

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

        --- 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!

[olbeup]

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.

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)

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

[Casimiro Noteví]

Empezado por olbeup

Como dije al principio, la DB puede tomar un tamaño enorme por no decir bestial, como dice la frase divide y vencerás.

Para gustos...

Si tuviera que 'dividir', en todo caso, tendría una Bd para todo menos para los documentos. En otra BD estarían únicamente los documentos.
Lo del tamaño de la BD, habría que definir lo de "bestial", he visto algunos usuarios que llaman bestial a unos pocos de megas, para mí "normal" sería rondando los 50 GB, muy grande puede ser varios cientos de gigabytes, y 'bestial' sería rondando el Tera.
No sabemos qué tamaño tendrá la BD que va a tratar Aldo porque no ha dado cifras.
Incluso recuerdo ahora a un usuario que llamó 'bestial' a una tabla en .dbf que tenía casi cuatro mil registros. Todo es relativo en este mundo

[olbeup]

Empezado por Casimiro Notevi

Para gustos...

Efectivamente, en la otra base de datos estarían los (JPGE, DOC, XLS, EMAIL, ETC) ya que estas son las que van a crecer.

Sobre el tamaño de las bases de datos, de momento no me he manejado con tamaño grandes, para mi grande es a partir del 1Gb

Aldo, el motor de base de datos SQL SERVER 2005 EXPRESS es el que yo utilizo no te vale para ti, porque el tamaño máximo de esta base de datos es de 4Gb y para el 2008 EXPRESS creo que lo han subido a 16Gb, con estos tamaños ni para café.

Un saludo

[Aldo]

Hola a todos. Como os había prometido, aquí tengo la solución al problema que he planteado y que os agradezco la atención que habéis prestado, pero me he decantado por esta solución.

1. En el lado cliente. En el procedimiento que se encarga de salvar los datos.

Código Delphi [-]
{ ATENCION: Las palabras en mayúsculas suelen ser constantes que definen los nombres de los campos y parámetros que se utilizan en cada uno de los 
procedimientos y funciones de la aplicación. Están declaradas en una unit aparte y no creo que sea relevante especificar aquí. Se entiene perfectamente }

var
   szFileName : String;
begin
   ...    
   With MyClientDataSet do
   begin
       ...
      { Asignar a la variable, el nombre del fichero que se debe guardar en el lado servidor  }
      szFileName := ‘Nombre de Fichero’;
      Params.ParamByName( QADDUPD_FILIACIONES_DOCUMENTACIONES_VFICHEROASSTREAM ).LoadFromFile( szFileName, ftBlob );
      ...   
   end; 
end;

2. En el lado capa de negocio hay más de un evento que hay que programar.

Código Delphi [-]

{ ATENCION: La función GetDatabaseNameFromSQLConnection() se encarga de devolver la ruta de la base de datos.
  Por razones obvias no la pongo aquí. 
  Se asume que la ruta final donde se guardarán los ficheros traidos desde los clientes será:
  DATABASE_PATH \ DOCUMENTACION_DIR \ ID_FILIACION   
}

{*******************************************************************************
* sqlQAddFilDocBeforeOpen: Evento OnBeforeOpen del query sqlQAddFilDoc que se
*                          ejecuta justo para crear el fichero que es pasado en el
*                          parámetro QADDUPD_FILIACIONES_DOCUMENTACIONES_VFICHEROASSTREAM
*                          del Query
********************************************************************************}
procedure TMyDataModule.sqlQAddFilDocBeforeOpen( DataSet: TDataSet);
var
   Param           : TParam;
   szFileName      : String;
   nId_Filiacion   : Integer;
   szIdentificador : String;
   Stream          : TStream;
begin
   with TSQLQuery( DataSet ) do
   begin
      { Obtener Ruta de la base de datos así como datos necesarios para definir la ruta  }
      nId_Filiacion   := Params.FindParam( QADDUPD_FILIACIONES_DOCUMENTACIONES_VID_FILIACION ).AsInteger;
      szIdentificador := Params.FindParam( QADDUPD_FILIACIONES_DOCUMENTACIONES_VIDENTIFICADOR ).AsString;
      szFileName      := ExtractFilePath( GetDatabaseNameFromSQLConnection() ) + DOCUMENTACION_DIR +  '\' + IntToStr( nId_Filiacion ) + '\' + szIdentificador;

      { Intentar crear las rutas de directorios para poder grabar el fichero }
      if ForceDirectories( ExtractFileDir( szFileName ) ) then
         begin
            { Buscar el parámetro que trae el fichero a guardar }
            Param := Params.FindParam( QADDUPD_FILIACIONES_DOCUMENTACIONES_VFICHEROASSTREAM );
            { Si lo encuentra }
            if Param <> Nil then
               begin
                  { Si se ha pasado algún fichero en el parámetro}
                  if not Param.IsNull then
                     begin
                        { Crear fichero }
                        Stream := TFileStream.Create( szFileName, fmCreate );
                        try
                           { Salvar fichero a disco }
                           Stream.CopyFrom( Param.AsStream, Param.AsStream.Size );
                        finally
                           Stream.Free;

                           { Guardar el nombre del último fichero creado, se usa en
                             otros eventos }
                           szLastFileName := szFileName;
                        end;
                     end;

                  { Elimina este parámetro de la colección de Params del Query
                    para que en el momento de ejecutar el S.P. del query, no dé
                    error, porque el S.P. no tiene este parámetro }
                  Params.RemoveParam( Param );
               end;
         end;
   end;
end;

{*******************************************************************************
* sqlQAddFilDocAfterOpen: Evento OnAfterOpen del Query sqlQAddFilDoc que se ejecuta
*                         para eliminar el fichero que se pudo haber creado, pero que no hay 
*                         que dejarlo allí, porque ha ocurrido un error en el proceso de creación
********************************************************************************}
procedure TMyDataModule.sqlQAddFilDocAfterOpen( DataSet: TDataSet);
begin
   { Si hubo error en el P.A. de crear una fila en la tabla de Filiaciones
   Documentaciones }
   if TSQLQuery( DataSet ).Fields.FindField( VRESULT ).AsInteger <= 0 then
      { Si el fichero guardado en la variable szLastFileName ( toma valor en el
       evento sqlQAddFilDocBeforeOpen ) existe, eliminarlo  }
      if FileExists( szLastFileName ) then
         begin
            SysUtils.DeleteFile( szLastFileName );

            { Intenta eliminar el directorio en el que estaba el fichero eliminado,
              si éste está vacío }
            RemoveDir( ExtractFilePath( szLastFileName ) );
         end;

   { Limpia la variable para otra ejecución }
   szLastFileName := '';
end;

Como conclusión final os diré que también programé una función par a una UDF que se ejecuta desde los triggers de AFTER DELETE y AFTER UPDATE de la tabla donde se almacena la referencia de los ficheros contenidos en el catálogo de documentos. Estos triggers se ejecutan para mantener la integridad referencial entre los registros de esta tabla en la base de datos y los ficheros físicos guardados en el disco duro del Servidor. Donde:

1. El caso del trigger AFTER DELETE, se ejecuta por razones obvias que debe eliminar el fichero del registro que se ha eliminado de esta tabla.

2. en el caso del trigger AFTER UPDATE, se ejecuta cuando se ha cambiado el nombre de un fichero por otro ( esto incluye no solo el nombre sino también su contenido ). En este caso se elimina el viejo fichero y solo queda guardado en el catálogo de documentos el nuevo fichero.


Por otro lado. Os explico que me decidí por esta variante, por todas las cosas que antes se han debatido en este hilo, más las condiciones reales de implantación de esta aplicación en el cliente final. Donde he tenido en cuenta lo siguiente:

1. No puedo contar con la base da datos sobre UNIX como me sugeristes, porque esto encarecería el proyecto, obligando al cliente final tener más de un servidor con distintos sistemas operativos, ya que de cualquier forma este cliente necesita el Windows en el lado Servidor, para que se ejecute también allí mi aplicación de la capa de negocios y otras aplicaciones que se ejecutan sobre windows.

2. El tamaño de la base de datos es algo a tener en cuenta sobre todo en los procesos de backups y restores.

3. El sistema propuesto por olbeup no me convence del todo, porque no me gustaría tener tantas bases de datos como pacientes hayan registrados en la aplicación. Además de que creo que la solución que ha propuesto no se refiere a bases de datos Firebird. Si es el caso, entonces soy yo el que no conoce esa nueva forma de referirte a otras bases de datos desde la base de datos actual. En resumen, el caso de '.dbo.' creo que es algo que se usa en las bases de datos de SQL Server y alguna otra, pero no en Firebird.

4. Por último y no menos importante, era mantener la transparencia de localización de los archivos en el Servidor sin tener que estar compartiendo directorios en la red para poder acceder a ellos y poder guardar y recuperar los ficheros de dichos directorios. Además de los inconvenientes que existen en windows con todo el sistema de Seguridad al compartir directorios en la Red.


Luego queda algo referente a la visualización de los documentos cada vez que el cliente así lo requiera. En ese caso me decanté por tener una tabla en memoria que solo contiene un registro con un camopo Blob en el que se almacena el fichero que es recuperado de su lugar físico del disco duro del servidor. Para ser mostrados en el lado cliente se trae una copia de dicho fichero y se visualiza con la función del API ShellExecute.

Aquí queda una cuestión interesante a tener en cuenta y es si utilizando la función Shellexecute se puede abrir dicho fichero en modo de solo Lectura, para que no pueda ser modificado por ningún cliente de la aplicación una vez que ya está guardado en el catálogo de documentos.

Tengo una vaga idea y es cambiarle los atributos al fichero y ponerle 'De solo lectura', pero no sé como se comportará cuando el fichero sea abierto por su aplicación. ¿ Alguna idea al respecto ?

Espero os haya servido de algo. Además si alguien encuentra algún fallo os agradezco que me lo hagan saber y así corregir y/o perfeccionar este planteamiento.