Catálogo de Documentos en el Servidor

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

[olbeup]

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.

Es verdad que el motor que utilizo es SQL SERVER, perdón, nose como se haría en Firebird.

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.

Si ésto es para un Hospital, Clínica, etc.., no crees que se cargara demasiado la red cuando hayan de 1 á x puestos copiando un fichero que tiene 10Mb o xxMb., no es lo mismo que los datos estén dentro de la base de datos que ella se encargará de administrar el envío por la red, que los tengas que coger fisicamente desde un directorio.

También has pensado si éste hospital, Clínica, Etc..., tiene una sucursal a 50Km ó 100Km de ésta y se quiera compartir los datos con ésta otra porque el paciente está de paso o se ha trasladado de localidad.

A mi parecer es mejor tener los fichero (JPGE, PDF, DOC, XLS, ETC..) dentro de la base de datos y separadas por pacientes y cómo tu has dicho cada paciente tiene su base de datos pero sólo de (JPGE, PDF, DOC, XLS, ETC..) los demás datos son en común.

Yo utilizo SQL SERVER cómo bien sabes, y dentro de la base de datos principal tengo un ficheros de FotosEmpleados, FotosVehiculos, DocumentosPDF, etc.. y sólo llevo no más de 100 fotos de empleados y la base de datos se ha disparado, me replanteo con lo que se ha tratado aquí es sacarla de hay y crear una base de datos nueva.

Un saludo.

[[Chris]]

Empezado por olbeup

También has pensado si éste hospital, Clínica, Etc..., tiene una sucursal a 50Km ó 100Km de ésta y se quiera compartir los datos con ésta otra porque el paciente está de paso o se ha trasladado de localidad.

Los datos igual tendrían que transferirse por red, no importa si estén dentro de la DB o en un directorio compartido en la sucursal principal. De hecho, almacenar los archivos dentro de una DB consume más recursos de red.

Empezado por olbeup

A mi parecer es mejor tener los fichero (JPGE, PDF, DOC, XLS, ETC..) dentro de la base de datos y separadas por pacientes y cómo tu has dicho cada paciente tiene su base de datos pero sólo de (JPGE, PDF, DOC, XLS, ETC..) los demás datos son en común.

Realmente no es así. Te podrías imaginar tener más de mil registos de pacientes? Eso equivaldría a tener más de mil bases de datos distintas. Darle mantenimiento a todas ellas se volvería un dolor de cabeza. Te imaginas en el trabajo que llevaría agregar un campo o una tabla más a la estructura de la DB? Amigo, las llavez foráneas se inventaron para esto. Es más económico en recursos técnicos y en procesamiento, mantener una única conexión que hacer muchas a distintas DB's.

Saludos!

[Casimiro Noteví]

Empezado por Aldo

No puedo contar con la base da datos sobre UNIX como me sugeristes, porque esto encarecería el proyecto...

Teniendo en cuenta que Linux (no Unix) cuesta cero euros

Pero, bueno, con tus comentarios, en general, creo apreciar que se trata de un pequeño hospital o una pequeña clínica, con algunos poquitos puestos y la información sería realmente poca, porque en caso contrario, vas a ir muy "vendido".
En fin, que tengas suerte con el proyecto.