Catálogo de Documentos en el Servidor

[Aldo]

Hola a todos.

Estoy desarrollando una aplicación en tres capas en Delphi XE y con el uso de DataSnap ( Firebird ). El objetivo es crear un catálogo de documentos en el lado servidor para guardar allí todos los ficheros que se quieran agregar al catálogo ( ficheros PDF, imágenes, Documentos de word, ficheros textos, etc. ). En la base de datos de firebird se guarda en una tabla la referencia de dichos ficheros. El tema es evitar que la base de datos crezca enormemente, ya que los ficheros pueden llegar a ocupar bastante.
Teniendo en cuenta las pros y contras de usar un campo BLOB en la tabla o usar el disco duro del servidor para guardar dichos ficheros. Puede alguien ayudarme a encontrar una solución en la que se pueda inicialmente pasar el archivo al lado servidor con el dataSnap que no incluya rutas físicos de red, etc?.
Quiero evitar con ello el tener compartido directorios en el lado servidor para que la aplicación cliente pueda copiar allí los ficheros que sean intoducidos en el catálogo. Así se evitarían todos los problemas de seguridad en la red. Por otro lado sería transparente desde el lado cliente, el sitio donde se guardan finalmente dichos archivos.

No sé si me he explicado correctamente. Pero por ejemplo he intentado algunas cosas, como:
1 . Crear un TParam y cargar el fichero en el parámetro y pasarlo a un ClientDataSet que es un Stored Procedure en el lado servidor. PERO. En el lado cliente funciona bien, pero no he encontrado en un TParam la función SaveToFile que si llegan a tener los TBlobField.
2. Con campos TBlobField si es posible hacerlo porque tiene las dos funciones ( LoadFromFile y SaveToFile ), pero necesita un DataSet cuando este es creado y no es el caso, yo necesito que esto sea independiente de una tabla de la base de datos.
3. No se me ocurre ninguna otra idea. Ayuda, Por favor.

Gracias por vuestro tiempo

[Casimiro Notevi]

¿Va a ser demasiado grande la BD si guardas los documentos en la misma?, ¿has hecho alguna estimación?

[Aldo]

La verdad es que si. Pueden ser escáneres, ortos o imágenes que pueden llegar a pesar más de 10 MB cada una de ellas y eso por cada paciente a lo largo del tiempo puede llegar a hacer que la base de datos crezca desmesuradamente.

Alguna otra sugerencia?

Gracias por vuestro tiempo

[olbeup]

Lo único que se me ocurre es, dividir las base de datos y tablas para que no sean tan enormes

Como bien dices si un paciente puede tener 10Mb de datos, multiplica eso por 250 pacientes que te da 2.5Gb por día, en un mes 78.64Gb, en un año c...ño, da error la calculadora.

Se puede hacer una base de datos principal que será: Hospital de Nsra. XY, dentro de esta base de datos, están las tablas, y las tablas en común son los pacientes, medicos, habitaciones, etc, cada paciente tiene su DNI, NIF, PASAPORTE, ETC, lo que sea para tomar referencia, la idea es coger algún dato del paciente que no se repita para crear una base de datos con el dato del paciente no modificable y tablas correspondientes a ese paciente y dentro de esas tablas sólo guardaremos los PDF, JPGE, DOC, XLS, ETC, ETC..., de esta forma cada base de datos sólo tendrá como máximo 50Mb por dar un poco más de cuello para los imprevistos por si hay que repetir pruebas.

Es sólo una idea

Un saludo.

[Casimiro Notevi]

Empezado por Aldo

Alguna otra sugerencia?

Las únicas sugerencias que existen son dos, ya sabes:

1. Guardas los documentos en la BD
2. Guardas los documentos fuera de la BD

De todas formas, no has respondido a cómo de grande puede ser la BD.

[Aldo]

Gracias por vuestra ayuda.

Pues teniendo en cuenta los cálculos que ha hecho olbeup, tomará un tamaño bastante grande en cuestión de tiempo. Se trata de guardar ficheros que son radiografías, Ortos, escáneres, ficheros PDF, Documentos de Word, correos electrónicos, etc. Los últimos no ocupan mucho, pero los primeros ( gráficos ) si que ocupan bastante.

Yo me he descartado por la segunda variante que propones. Salvar los ficheros fuera de la base de datos pero el dilema que tengo es como copiar el archivo desde el cliente hasta el servidor sin tener en cuenta los permisos de red, etc, sin tener que compartir directorios, etc y que sea transparente para la aplicación cliente.

La idea es implementar un método del Servidor de aplicaciones en el que se pueda mandar el fichero ( Ej: Como lo hace los campos Blobs o los Params ) y que el Servidor de aplicaciones se encargue de guardar el fichero pasado en su destino final. Pero lo que no encuentro es como pasar el fichero al estilo de los TBlobField o de un TParam.

Un saludo

[Casimiro Notevi]

Empezado por Casimiro Notevi

1. Guardas los documentos en la BD
2. Guardas los documentos fuera de la BD

Creo que no te he entendido esto:

Empezado por Aldo

Yo me he descartado por la segunda variante que propones.

Porque descartar es:

descartar

• desechar, eliminar, prescindir, suprimir, repudiar, recusar, excluir
• abstenerse, excusarse, evitar, rehuir

Empezado por Aldo

Salvar los ficheros fuera de la base de datos

Entiendo que la que has descartado es la 1º, guardar en la BD. O sea, que quieres guardarlos en un directorio del servidor.

[Aldo]

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

[Delfino]

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

[Aldo]

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

[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 Notevi]

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 Notevi]

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 Notevi]

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.