Sistema de cuentas

[HombreGordo]

Buenas. ¿Me pueden echar una mano (por favor) con un sistema de cuentas? Sé que mi pregunta es vaga, pero me gustaría que alguien me ayudase a diagramar y/o darle forma a la idea. Más o menos tengo una idea, que sería algo así como una base de datos, que conserve a los usuarios, y en base a esa referencia, cargue la información de ese usuario, y esa información tendría que ser, como las subcuentas pendientes que tiene el usuario, como sus deudas con el sistema de pago.

¿Posee alguien una guía o alguna forma de estructura y/o código de ejemplo que me pueda ayudar a llevar esta idea al programa? ¿Qué sistema de bases de datos me recomendarían para trabajar esto (BDE, ADO, etc etc etc...)? (Poseo Delphi 7 y Delphi 2007)

[TOPX]

Buenas,

Yo no me ofrezco a ayudar a diagramar y/o dar forma a la idea, pero sí a mostrarle unos recursos que le pueden servir como guía:

• http://www.databaseanswers.org/data_...ment/index.htm
• http://www.databaseanswers.org/data_...ls_payment.htm
• http://www.databaseanswers.org/data_...oans/index.htm

Y de paso a los compañeros del club, ese banco de modelos ER está interesantísimo...

[HombreGordo]

Eh tío, gracias por las guías, quizás era lo que estaba buscando y no sabía por donde empezar. Sin embargo, más respuestas a este hilo serán muy agradecidas.

[roman]

Empezado por TOPX

Y de paso a los compañeros del club, ese banco de modelos ER está interesantísimo...

Pues sí que se ve interesante. Así como para cuando esté uno falto de inspiración, hay ahí muchos puntos por donde empezar. Gracias por el enlace.

// Saludos

[HombreGordo]

Bueno, lo que necesito es más sencillo, es algo como un sistema de alquiler que determine el precio por períodos de alquiler, pero que vaya "contabilizando" si el cliente abona, y cosas por el estilo. De manera que cuando haga referencia a un cliente en la base de datos, cargue sus cuentas pendientes en alquiler, y pueda contabilizar, a la vez que se puedan agregar artículos a la cuenta del alquiler. Eso sería viniendo a ser el modelo básico de lo que hay que programar.

[[Delphius]]

Hola HombreGordo,
No quisiera "sonar" un tanto atrevido, pero me parece más adecuado que nos vayas comentando tus avances y en la medida que continúas y encuentras dudas y problemas nos los haces saber.

Por poco el hilo me suena a hazme la tarea, se que no es tu intención. Pero es que el problema de que nosotros demos el primer paso y te propongamos nuestra visión del tema puede hacerte más o menos difícil comprender la idea.
Cada uno tiene una manera de enfocar y ver las cosas, y si te proponemos un modelo a seguir, existe la posibilidad de que para ti te sea más complicado de seguir, y entender.

Da el primer paso tu, y en base a ello te ayudamos ¿Te parece bien?

Saludos,

[HombreGordo]

Yo mismo lo he notado, gracias por tu comentario. Jejej, disculpen la molestia, y así será, iré dando los pasos y conforme a las dudas, plantearé las preguntas, no sin antes haberlo intentado por mí mismo.

Editado: He revisado los modelos que TOPX puso, ya he aclarado la diagramación en mis papeles, sin embargo, la duda real que se me presenta, es la siguiente:
Dada una base de datos con una tabla que tiene "Clientes" con sus referencias numéricas, debe haber alguna forma de poseer otra tabla, donde se conserven las cuentas de dichas referencias, es decir, las entradas que están relacionadas con dichos "Clientes", y aparte de eso, debería poder importar las referencias de los artículos que se alquilaron que se conservan en las entradas de la tabla de las cuentas. Algo como esto:

Clientes ---> Tabla de cuentas pendientes <--- Inventario (artículos requeridos)

(Lo que está en cursiva, vendría siendo como una especie de tabla "principal" y lo que está en negrita vendrían siendo como las tablas que se van a correlacionar dentro de las entradas de la tabla de cuentas)

Lo que necesito es aprender a interrelacionar tablas, y es lo que realmente quise preguntar al inicio, pero no me supe explicar.

Gracias de antemano (y gracias por su comprensión también)

[[Fenareth]]

Hola HombreGordo !

Pues mira en base a lo que ya pensaste, podríamos aterrizarlo en 3 Tablas cierto ?...

Una de Clientes con todo el detallado de su información personal (un ID, nombre, domicilio, etc.)

Otra de Movimientos en donde puedas capturar el detalle de salidas y entradas que ocasiona un cliente.

Una más de Productos en donde puedas tener el detalle de la información de los productos que se manejen.

Ahora, me gustaría saber que tanto sabes de relaciones, campos llave, integridad referencial, campos, registros y todo aquello que se relaciona con el diseño de las Bases de Datos. Estos conceptos son importantes al momento de pensar el cómo funcionará tu sistema.

Saludos

[HombreGordo]

Ah, sencillo es así:

Está la tabla de Clientes que contiene los datos de los clientes, pero ésta a su vez contiene para cada cliente, un número de referencia, como un identificador, quizás pueda ser su cédula de identidad, o RIF empresarial. A partir de ese número, se cargan sus movimientos según la tabla de Movimientos que contiene sus cuentas pendientes, como alquileres en progreso. A su vez, esas cuentas, tienen unas referencias que son los artículos que alquiló, son referencias que vienen de una tabla llamada Inventario.

Conozco los campos clave, que son aquellos en donde los registros no pueden repetir sus valores, conozco los tipos de campos, tengo nociones de SQL, unos conceptos básicos de BDE. Sin embargo, "empotrar" estas referencias en la tabla Movimientos es lo que necesito aprender. Y otra cosa primordial, es que así como inserto datos en una tabla usando sentencias SQL, me gustaría aprender a extraer los datos de un determinado campo, pero no para llevarlos a un DBGrid como he venido haciendo, si no que pueda agarrar la cadena directamente del registro que se muestra en un determinado campo.

[[Delphius]]

Empezado por HombreGordo

Ah, sencillo es así:

Está la tabla de Clientes que contiene los datos de los clientes, pero ésta a su vez contiene para cada cliente, un número de referencia, como un identificador, quizás pueda ser su cédula de identidad, o RIF empresarial. A partir de ese número, se cargan sus movimientos según la tabla de Movimientos que contiene sus cuentas pendientes, como alquileres en progreso. A su vez, esas cuentas, tienen unas referencias que son los artículos que alquiló, son referencias que vienen de una tabla llamada Inventario.

Conozco los campos clave, que son aquellos en donde los registros no pueden repetir sus valores, conozco los tipos de campos, tengo nociones de SQL,

Hasta aquí vamos bien.

Empezado por HombreGordo

unos conceptos básicos de BDE.

Y aquí la arruinas ¿DBE? Se desaconseja seguir usando, ya ha quedado un tanto obsoleto y practicamente ha quedado por una cuestión de compatibilidad hacia atrás.

Empezado por HombreGordo

Sin embargo, "empotrar" estas referencias en la tabla Movimientos es lo que necesito aprender.

Disculpa, pero no comprendo lo que dijiste. ¿Podrías aclararlo por favor? ¿A que te refieres con "empotrar".

Empezado por HombreGordo

Y otra cosa primordial, es que así como inserto datos en una tabla usando sentencias SQL, me gustaría aprender a extraer los datos de un determinado campo, pero no para llevarlos a un DBGrid como he venido haciendo, si no que pueda agarrar la cadena directamente del registro que se muestra en un determinado campo.

Por lo que entiendo, lo que haces es mediante instrucciones SQL del tipo INSERT insertas elementos a tus tablas.

¿Tu pregunta al respecto para extraer datos viene a por saber como consultar algunos campos de forma "individual"? La verdad es que no logro comprenderte. Dime si entiendo bien: ¿Dices que para consultar información lanzas una instrucción SQL del tipo SELECT y muestras los datos en un DBGrid? ¿Quieres leer estos datos sin tener que usar DBGrid?

Veamos como te puedo explicar el acceso a campos.
Como dices que usas DBE basaré la explicación en ellos.

Mediante un TTable podemos acceder a los campos de las siguientes formas:

1. Forma Directa

Consiste en armar los campos persistentes, es decir creados en tiempo de diseño. Para ello solo hay que tener previamente establecido la tabla y la base de datos a la que vamos a acceder. Luego, con solo presionar el botón secundario sobre el componente y pulsar "Fields Editor" nos aparece un cuadro de díalogo. Luego volvemos a presionar el botón secundario y ahora en "Add Fields".

De esta forma conseguimos añadir ya los campos de forma persistente.

Si te fijas en Objet TreeView notarás que dentro de la rama Fields correspondiente a la tabla aparecen listados dichos campos. Notarás que a cada uno Delphi le ha asignado un nombre. Este nombre obedece a una simple regla:

Nombre del TTable + Nombre del Campo en la DB

Por ejemplo, si el TTable se llama tbCliente y el campo es ID, el nombre que se obtiene es tbClienteID.

Ahora para hacer uso de este campo podemos hacer algo como esto:

Código Delphi [-]
MiTablaMiCampo.Value := ...... // para establecer el valor
variable := MiTablaMiCampo.Value; // para leer el valor

Tanto el valor leído como el a ingresar o modificar corresponderá al registro en el cual esté parado.

Esta forma al ser la más directa es la más segura para acceder al campo. Como desventaja se podría decir que hace más grande al archivo dfm y ocupandonos más memoria.

2. Forma intermedia

La forma intermedia (si se lo puede llamar asi) es emplear la propiedad Fields del TTable tanto para leer como para asignar:

Código Delphi [-]
MiTabla.Fields[IndiceCampo].Value := .... 
variable := MiTabla.Fields[IndiceCampo].Value;

Siendo IndiceCampo un valor, constante, o una variable entera mayor o igual a cero y menor a la cantidad de campos.
IndiceCampo indica en forma numérica al campo al que deseamos acceder. Los campos se comienzan a contar en el orden en que fueron descriptos en en la tabla. Supongamos que el campo ID fue definido en la primera posición, por tanto el valor que le corresponde es el 0.

Esta segunda forma es menos directa, el compilador debe hacer un poco más de trabajo para localizar el campo. Se accede mediante el índice y esto implica posicionarse en la lista del los campos. Como desventaja de este método se puede decir que ante algún cambio en la tabla corremos el riesgo de acceder al campo erroneo si no tenemos cuidado.

Fields[] nos regresa un objeto TField. En el ejemplo asumí que no nos interesa guardar en una variable el objeto y nos ponemos a hacer uso de dicho objeto (propiedad Value).

3. Forma Indirecta

Esta última forma de acceder al campo es la más "lenta" de todas. Consiste en buscar al campo dentro de la lista por el nombre, en vez del índice, mediante el método FieldByName:

Código Delphi [-]
MiCampo := MiTabla.FieldByName('NombreCampo');
MiCampo.Value := .....
variable := MiCampo.Value;

Código Delphi [-]
MiTabla.FieldByName('NombreCampo').Value := ....
variable := MiTabla.FieldByName('Nombrecampo');

FieldByName devuelve la referencia al objeto TField que representa al campo buscado. Si lo encuentra nos los regresa, en otro caso, conseguiremos una excepción. Notarás que mostré dos ejemplos parecidos: en el primero guardo en una variable MiCampo del tipo TField el resultado de FieldByName y luego trabajo con ella. En el segundo, simplemente me evito dicha variable y hago todo al vuelo.

Las necesidades te dirán que hacer... en algunos casos será necesario guardar dicha referencia, en otros no.

Como ventaja de esta forma se puede decir que es las más flexible puesto que nos evita posibles líos ante los cambios en la estructura de la tabla: si se mueven los campos de lugar no interesa. Si el campo existe, FieldByName siempre lo encontrará.

Del mismo modo que se usa el TTable, podemos acceder a los campos mediante un TQuery. La diferencia está en que ahora es necesario contar con una instrucción SQL válida indicando la/s tabla/s a las que deseamos consultar.
También disponemos de campos persistentes, Fields y FieldByName.

Hay otra alternativa para acceder a un campo que no he mencionado: FindField(). Este método (función) nos regresa el objeto que representa al campo en caso de encontrarlo, de otra manera nos devuelve vacio (nil). Ha diferencia de FieldByName este método no arroja excepción.

No se si con acceder a los campos te refieres a lo que he dicho. Te agradecería que me hicieras saber si te ha sido de utilidad.

Saludos,

[HombreGordo]

Sí, ha sido justo a lo que me refería Gracias Delphius. Sin embargo, el problema que se presenta, es a la hora de cargar dichas "Cuentas" por usuario, debido a que la tabla Movimientos es la que conserva las referencias a las cuentas pendientes, en ese caso, yo no tendría problema en que cada cuenta de alquiler, fuesen tablas también creadas con sentencias SQL, con otra estructura, que permita contabilizar las mismas. Espero que de esta manera no se vuelva muy pesado el programa . A menos que alguien me pueda sugerir una forma diferente de cómo hacer esto, jejeje, creo que soy un poco rústico con las bases de datos al no saber como optimizar el trabajo de las mismas, por lo menos al momento de aligerar la carga.

EDITADO: Utilicé la forma intermedia para obtener los datos.