Usted que haría si.... :

[sercornejov]

Hola foristas.

Hace tiempo que no molestaba por aca...

Un cliente me pide una aplicación para una comercializadora de café. La cosa es para la parte contable. Los puntos críticos a la hora de decidir cual motos de DB usar son:

1. acceso de hasta 8 usuarios a la misma tabla de manera simultánea.
2. Alto número de registros para un periodo mensual (65000) de una de las operaciones (compra a campesinos).
3. Manejo de procedimientos almacenados
4. Concejos para preparar el mejor café colombiano

bueno, aunque el punto 4 ya lo solucioné, los tres primeros me tienen en vilo.

Yo he tranajado con FireBird 1.5, con una base de datos que contiene tres tablas grandes... Bueno, realmente una de ellas contiene 60.000 fotos en formato JPG (los archivos de estas fotos pesan solo 4K por separado) y hasta el momento funciona bien, aunque al iniciarla se demora como 90 segundos para entrar (esto es: cargando y abriendo las tablas que debe usar de manera inmediata a la apertura) y ademas el tamaño del archivo ya es de 550 MB, lo cual me parece un poco grande para una base de datos que se debe mover en RED.

Con lo anterior, no se si sea bueno manejar una base de datos como esta, que genera un solo archivo y que su tamaño puede ser muy muy grande, pues los datos de la comercializadora de café son realmente grandes. Solo la transaccion de compras a campesinos puede generar 7 y medio millones de entradas en un año

Bueno, pues el hilo queda con varias incognitas:

¿Debo usar FireBird?
Si la primera respuesta es NO: ¿Que debo usar?
¿Porque el archivo de Firebird es de 550 MB con 60.000 fotos adentro?
¿Es eso normal o es así de grande por las fotos?
¿Se puede en Firebird manajar daca año en archivos separados, pero que a la hora de consultar se pueda hacer en todo los años disponibles?
¿Es mejor dejar reposar el cafe durante 15 minutos y rocialo con agua fria antes de servirlo?
¿Mi mamá me mima?

Gracias por sus respuestas...

Sergio

[jachguate]

Empezado por sercornejov

Yo he tranajado con FireBird 1.5, con una base de datos que contiene tres tablas grandes... Bueno, realmente una de ellas contiene 60.000 fotos en formato JPG (los archivos de estas fotos pesan solo 4K por separado) y hasta el momento funciona bien

No conozco tu diseño, pero aún así casi me atrevo a asegurarte que seguirá funcionando igual de bien por mucho, mucho tiempo..

Empezado por sercornejov

aunque al iniciarla se demora como 90 segundos para entrar (esto es: cargando y abriendo las tablas que debe usar de manera inmediata a la apertura)

Esto es una barbaridad!! Te recomiendo revisar que información es la que te estas trayendo al cliente... independientemente de la cantidad de datos almacenados en el servidor, el cliente debiera arrancar en un abrir y cerrar de ojos.

Aqui, es importante aclarar que seguramente hay algo de "diseño" que mejorar, pero no es deficiencia de firebird, son las operaciones que vos estas haciendo.

Empezado por sercornejov

y ademas el tamaño del archivo ya es de 550 MB, lo cual me parece un poco grande para una base de datos que se debe mover en RED.

Hay algo de confusión aqui. El archivo de la base de datos jamás se moverá completo en la red. Por los pares trenzados (o el ambiente) viajarán únicamente los datos que tu aplicativo mande traer del servidor. Así, podes tener una base de datos de varios gigas, o teras, y traer al cliente solo un puñado de registros sin ningún tipo de inconveniente.

Empezado por sercornejov

Con lo anterior, no se si sea bueno manejar una base de datos como esta, que genera un solo archivo y que su tamaño puede ser muy muy grande

Creo que queda aclarado en el punto anterior, ¿no?

Empezado por sercornejov

Bueno, pues el hilo queda con varias incognitas:

¿Debo usar FireBird?
Si la primera respuesta es NO: ¿Que debo usar?

Firebird podria funcionar bien en ese entorno. Si el presupuesto lo permite, podrias mirar hacia oracle, que por estos días no está tan caro si es para tan solo 8 usuarios. De entrada yo no recomendaría SQL Server, pero es que nunca lo hago..

Empezado por sercornejov

¿Porque el archivo de Firebird es de 550 MB con 60.000 fotos adentro?
¿Es eso normal o es así de grande por las fotos?

Bueno, a mi me parece normal y no creo que debas preocuparte por el tamaño del archivo. Lo importante, en todo caso, es que sea eficiente. Hoy día, los discos son tan baratos, que toda la paranoia pasada por ahorrar espacio es solo una anécdota. Si te interesa comprender, de cualquier forma, porque es mas grande que 60,000 * 4k, te puedo decir de manera rápida varias cosas:

• La base de datos está organizada en páginas, que son todas de un mismo tamaño. Así, en ocasiones puede haber un desperdicio considerable de espacio debido a que no todo cabe exactamente en una página. Supongamos el caso de una imágen de 4K. Si tenes páginas de 4K, una fotografía deberá dividirse en dos páginas (debido a que cada una ocupa un número fijo de bytes de cabecera). En la primera página, se almacenarán los 128 bytes de cabecera (tamaño supuesto), mas 3960 bytes correspondientes a la fotografía mas 8 bytes con un puntero a la página que contiene el siguiente segmento. En la segunda, entonces, se almacenarán 128 bytes de la cabecera mas 136 bytes restantes de la fotografía. El resto del espacio queda "desperdiciado". Así, el almacenamiento de una sola fotografía puede obligar a ocupar realmente en disco 8K. Si tuvieses páginas de 2Kb. una fotografía de 4 seguramente se almacenaría en 3 segmentos, ocupando 6Kb.
• Además de las propias fotografías, en la base de datos se almacenan el diccionario de datos, indices y otras estructuras necesarias para la operación de la misma. Todos estos objetos también están sujetos al almacenamiento en páginas del que hablé en el punto anterior, originando cierto desperdicio.
• El tamaño de página es ajustable al momento de crear la base de datos, con lo que podes minimizar el efecto en caso estes ejecutando en medios muy caros (lo que sería realmente extraño)... ahora podes tener 200 Gb. por algo mas de 100 dolares acá en latinoamérica. Eso significa que tu base de datos puede crecer y almacenar unos 22 millones de fotos en gastando solo 100 dolares.
• Mas importante que cuanto espacio ocupa en disco un solo registro, en este caso es, a mi criterio, cuantas veces tendrá que leerse este disco disco (phisical read) para obtener una fotografía. En este caso yo preferiría mil veces dejar páginas de 8Kb (con un tremendo desperdicio), y traer toda una imagen en un solo acceso a disco, que provocar 5 accesos en páginas de 1Kb. con tal de ahorrar espacio, debido a que a diferencia del espacio, el tiempo, mi querido amigo, el tiempo es oro!!. Si un acceso a disco tardara 60 milisegundos, entonces el diseño de página mas grande nos devuelve un registro en ese tiempo, mientras que un diseño de página de 1Kb. podria tardar hasta 300!!, provocando un espantoso cuello de botella que relentizaría la aplicación completa (5 veces mas lenta la gran mayoría de las veces, en este hipotético caso).

Empezado por sercornejov

¿Se puede en Firebird manajar daca año en archivos separados, pero que a la hora de consultar se pueda hacer en todo los años disponibles?

Esto es una idea concebida en tiempos de los sistemas de escritorio. Con una base de datos relacional bien diseñada, no creo que sea necesario. Cuando mucho, separar la información internamente en diferentes tablas. Si te decantaras por Oracle, podes tener todo en una sola tabla con diferentes particiones (por año, por ejemplo).

Empezado por sercornejov

¿Es mejor dejar reposar el cafe durante 15 minutos y rocialo con agua fria antes de servirlo?

Se que en esto no nos vamos a poner de acuerdo, pero me parece que es mejor el café de Guatemala..

Empezado por sercornejov

¿Mi mamá me mima?

Seguramente...

Empezado por sercornejov

Gracias por sus respuestas...

Por nada.... se aceptan pagos en sacos de café (aunque sea Colombiano.. )

Hasta luego.

[lbuelvas]

Hola foro,

¿Se puede en Firebird manajar daca año en archivos separados, pero que a la hora de consultar se pueda hacer en todo los años disponibles?

Yo recomendaria que lo manejaras en una sola Base de Datos, se simplifican la organizacion y l manejo de las consultas.

La unica limitación sobre el manejo en un unico archivo (que es la forma original que trabajan Firebird e Interbase) esta dada no por el motor, sino por el sistema operativo, por ejemplo, Windows limita sus archivos a 2Gigabytes. Casualmente en estos dias a un cliente cuya BD tiene cuatro años de trabajo (es para una empresa de salud) empezo como a ponerse lento el sistema y a detenerse.

Resulta que la BD ya estaba al limite de esos 2 Gigas, entonces se hizo un backup y el restore se lanzo a dos archivos, uno de 2 gigas y el otro para que la base de datos siga metiendo paginas de informacion alli. Consulta la documentacion para hacer el restore de esa manera.

Te recomendaria Firebird, pero para volumnes de datos grandes utiliza un servidor basado en Linux (es mucho mas rapido).

Oiga chino yo soy incha de Nacional, cambiate el dibujito (es broma, America es un gran equipo)

Luis F. Buelvas T.

[Neftali [Germán.Estévez]]

Antes de nada te recomiendo éste hilo:
http://www.clubdelphi.com/foros/showthread.php?t=22211


Es una comparativa de varios SGBD's Open Source; Tal vez eso resuelva algunas de tus dudas...

En cuanto a los demás...


Hola foristas.
==> Hola.

...aunque al iniciarla se demora como 90 segundos para entrar (esto es: cargando y abriendo las tablas que debe usar de manera inmediata a la apertura)

==> Eso es mucho tiempo; Revisa el Tema de Abrir Bases de datos de FB, porque me suena que hay solución para eso. Además si cargas tablas, no las cargues todas en memoria, utiliza cursores de tipo Servidor (cargan registros a medida que los van necesitando -si quieres más info sobre ésto hablamos en otro mail...-)


...y ademas el tamaño del archivo ya es de 550 MB, lo cual me parece un poco grande para una base de datos que se debe mover en RED.
==> Cualquier Base de Datos un poco seria tiene eso y más... que no te preocupe. Otro tema es cómo estás guardando las fotos; Tal vez habría que guardarlas en formato compromido o incluso estudiar el guardarlas fuera dela Base de Datos (no soy partidario de ésta segunda opción), pero se puede estudiar...



...no se si sea bueno manejar una base de datos como esta, que genera un solo archivo y que su tamaño puede ser muy muy grande, pues los datos de la comercializadora de café son realmente grandes. Solo la transaccion de compras a campesinos puede generar 7 y medio millones de entradas en un año
==> Con más razón para usar una Base de Datos "como esta" (me refiero a un SGBD); Si estás pensando en Bases de Datos con tablas por separado tipo Paradox, DBase y demás olvídalo.

¿Debo usar FireBird?
==> No creo que sea un mala opción (revisa el LINK del principio)



Si la primera respuesta es NO: ¿Que debo usar?
==> Creo que una alternativa puede ser SQLServer; Nosotros la utilizamos con mucho más volumen que el que comentas y va bien; Pero eso depende mucho también de las infraestruras que respaldan (Servidores, Redes, comunicaciones,...) De todas formas ya sabemos el inconveniente/desventaja más grande de SQLSever: $$$$$$$$$$$$$


¿Porque el archivo de Firebird es de 550 MB con 60.000 fotos adentro?
==> Buena pregunta. Puedes hacer la prueba; Duplica la Base de Datos, elimina las fotos (DELETE o UPDATE), haz un Backup/Restore y a ver qué tamaño queda...



¿Es eso normal o es así de grande por las fotos?
==> Depende de cómo las guardes.


¿Se puede en Firebird manajar daca año en archivos separados, pero que a la hora de consultar se pueda hacer en todo los años disponibles?
==> Se podría, pero no lo tendrá que hacer FB, lo tendrás que hacer tú. Se puede utilizar un UNION, pero habría que ver qué tipo de consultas necesitas....


¿Es mejor dejar reposar el cafe durante 15 minutos y rocialo con agua fria antes de servirlo?
==> Me gusta Caliente, muy, muy caliente...


¿Mi mamá me mima?

==> Claro, como debe ser.... La mama siempre será la mamá...

[sercornejov]

Gracias a todos.

Pues lo de la manera de cargar la base de datos, no se, simplemente la coloco en el directorio de datos y en delphi la abro mediante:

procedure TdmPpal1.DataModuleCreate(Sender: TObject);
var
  registro:TIniFile;
  conexionL,conexionR:widestring;

begin
  registro:=TIniFile.Create(ExtractFilePath(Application.ExeName) + 'IDCFac.reg');
  red:=StrToInt(registro.ReadString('RED','EstaEnRed',''));
  conexionL:=registro.ReadString('BASEDATOS','local','');
  ruta:=registro.ReadString('DDIRBASE','dirbaseLocal','');
  conexionR:=registro.ReadString('BASEDATOS','red','');
  rutared:=registro.ReadString('DDIRBASE','dirbaseRed','');
  rutadatos:=ruta+registro.ReadString('DDATOS','datos','');
  rutadatosred:=rutared+registro.ReadString('DDATOS','datos','');
  rutareportes:=ruta+registro.ReadString('DREPORTES','reportes','');
  rutareportesred:=rutared+registro.ReadString('DREPORTES','reportes','');
  case red of
    0: fbFac.databasename:=conexionL;
    1: fbFac.databasename:=conexionR;
  end;
  try
    fbFac.Connected:=true;
    except
      showmessage('No se puede conectar a la Base de Datos. Contacte al proveedor: 310-6976764');
      application.Terminate;
  end;
  fbtra.Active:=true;
  fbtblCliente.Active:=true;
  fbtblFactura.Active:=true;
  fbtblUsuario.Active:=true;
  fbtblDetFac.Active:=true;
  fbtblInsumo.Active:=true;
  fbtblNumFac.Active:=true;
end;

ese datamodule se carga de primeras. no se que deba hacer para el arranque mas rápido

Lo de la paginación grande, pues lo voy a probar (Ha de funcionar)

Por lo demas, entendido, anotado y en via de uso

Gracias

P.D. para jachguate

No es con animo de controversia, pero el mundo ama el café excelso colombiano...

[jachguate]

Que tal.

Pues lo que corresponde es, con cronómetro en mano, seguir paso a paso la ejecución de este método, a partir de la línea:

Código Delphi [-]
    fbFac.Connected:=true;

Luego, volvé aqui con una estadística, digamos el promedio de ejecución de cada línea después de unas 5-10 corridas y vamos viendo de que puede tratarse el asunto.

Hasta luego.



pd.
[quote=sercornejov
P.D. para jachguate

No es con animo de controversia, pero el mundo ama el café excelso colombiano...[/QUOTE]

Te lo dije... no nos vamos a poner de acuerdo en ese punto.. . Solo he de decir que el café de altura de Guatemala es reclamado por muchos..

[roman]

Empezado por jachguate

Solo he de decir que el café de altura de Guatemala es reclamado por muchos

// Saludos

[jachguate]

[Migpal]

Debrias cambiar de equipo,

[nemesio]

La lentitud al abrir las tablas puede ser porque los select de las tablas estén trayendo todos los registros. Eso sucede cuando usamos SELECT .... FROM TABLA, y no colocamos los registros que queremos traer con un where.

[kalimero]

Hola.
Yo creo que deberias revisar la apertura de las seis tablas despues de abrir la base de datos.
Saludos

[aledieb]

Tu aplicación tarda porque abris las tablas al principio, hace una prueba:

No abras las tablas en el datamodule y pone un boton en algun lugar y abri las tablas en el click del botón vas a ver la diferencia.

Yo te recomiendo que no utilizes tablas, y menos aun que la abras al principio de la aplicación, abrilas solo cuando las tengas que usar, y en lugar de tablas utiliza querys o mejor aun los ibdataset.

[[Lepe]]

Recordar que el hilo es del 21/06/2005 y Migpal sólo ha hecho un comentario jocoso.

Lo siento si han leido todo el hilo... aunque bueno, tampoco está demás

Saludos