Como introducción grábate estas tres frases en la cabeza. Son la biblia, las tres reglas de oro, del programador:
1.- "Dame tu código y después de dos horas de mirarlo aún no sabré bien qué hace tu programa. Dame tu estructura de datos y te diré si tu programa está bien hecho en cinco minutos".
2.- "Antes de empezar un programa sólo sabes una cosa segura: Hagas lo que hagas, más tarde tendrás que modificarlo".
3.- "Dentro de un tiempo no recordarás lo que has hecho".
Por partes:
Primero lo bueno. Hacer constar que el programa, para ser el primero que haces en
gambas, bien... en cuanto a lo que es el manejo de
gambas. Quiero decir que has entendido cómo manejar los formularios, abrirlos, cerrarlos, acoplar los eventos a los controles, aspecto, colores, etc.
Sin embargo, me preocupan dos cosas cuya crítica depende del nivel de tu curso y de tus aspiraciones. Me explico:
-Si estás estudiando informática en la universidad como podrías estar estudiando veterinaria y lo único que quieres es aprobar la asignatura y olvidar todo esto cuanto antes... vale. El que el programa esté bien o mal lo juzgará tu profesor, que es el que sabe el nivel que exige y el nivel de conocimientos que se supone que tienes que alcanzar. Aprueba, apaga y vámonos. En esta caso no sigas leyendo.
-Si estás en la Universidad con ambición de forjarte un futuro en el tema de la programación y algún día diseñar programas de gestión "en serio" es otra cosa y lo que sigue tal vez te interese y ayude.
Analizando tu programa con las gafas de juzgar a un aspirante a informático profesional... la cosa no es tan buena.
A continuación te voy a decir las deficiencias que encuentro en tu proyecto y lo que indican, en mi opinión:
Si tu código es excesivo en longitud, lleno de redundancias y cosas así... es normal. Es tu primer programa en éste lenguaje y todo es perdonable. Si tienes tendencia al interface caótico, es normal, es fruto de descubrir el manejo de colores, formas y demás y de experimentar con ellos. Pecados de juventud. La falta de conocimientos de la herramienta se soluciona manejándola. No problema.
Pero, la falta de conocimientos básicos de análisis de datos, la falta de comprensión de lo que son bases de datos relacionales y la falta de tiempo dedicado a analizar los datos que tu aplicación necesita... es preocupante.
No veo en tu base de datos prácticamente ninguna relación de tablas. No veo ninguna optimización de datos. Por ejemplo tienes 6 tablas en tu base de datos. Quitando la que usas para el login de usuario y la que usas para el contador de vacunas, quedan 4. En todas ellas repites campos Número de historia, cedula, nombre, apellido, etc., etc. En todas.
Tu usuario se verá forzado a teclear una y otra vez los mismos datos para manejar sólo el historial de una persona. Tu base de datos crecerá innecesariamente en tamaño con datos cuatruplicados que, además, darán lugar a errores (si aquí lo tecleo mal, si aquí pongo acento y aquí no, si aquí me equivoco de nombre y aquí no, etc. etc.)
Eso no es una base de datos.
Por otra parte, como error más claro, tienes una tabla con 160 campos que es inmanejable. Seguro que te has pasado horas ajustando checkbox por aquí, y por allá ¡El código del formulario tiene 7.793 líneas, por Dios! para controlar un porrón de campos... que se reducen a tres o cuatro si analizas bien el problema.¿Y si te dicen que hay que añadir tres más? Y si hay que eliminar otros dos? ¿Y si este no debe ser un checkbox sino una fecha? Volverías a pasar otras tropecientas horas moviendo controlitos de aquí para alla... (Regla de oro número 2)
Te adjunto una base de datos con una sugerencia de cómo haría yo la estructura de datos de tu aplicación, sólo de la parte de la historia médica, la que tú manejas con la tabla contactos. Verás que esa tabla monstruo de 160 campos se ha convertido en cuatro tablas de 19, 5, 4 y 7 campos. Con 35 campos en total no sólo se puede manejar toda la información que tú manejas con 160, sino mucha más (¿por qué limitarse a tres parientes si puedes meter el árbol genealógico entero? ¿Por qué limitarse a controlar 115 parámetros médicos si puedes controlar infinitos?, etc. etc.
No he incluído en la estructura las relaciones entre tablas, pero con el nombre de los campos índice creo que las entenderás sin problemas.
No es perfecto, es sólo una aproximación hecha a correprisa de cómo enfocaría yo el asunto, pero una estructura acorde al espíritu de las bases de datos relacionales luego te ahorran muchísimos dolores de cabeza. Te lo aseguro.(Regla de oro número uno)
Para resumir, consejos que te doy:
1.- Analiza muy bien los datos que necesitas antes de empezar a escribir código y poner colorines, lo agradecerás. Márcate para ello una guía que responda a algunas preguntas muy sencillas:
-¿Este dato ya lo tengo en alguna otra tabla? ->Relacionar tablas, no duplicar.
-¿Este dato es fijo (como la fecha de nacimiento) o es variable (como el número y tipo de vacunas, por ejemplo).
-¿Este dato depende de otro o es autónomo? (Por ejemplo: ¿Para qué pedir si es analfabeto si ya le pido el nivel de estudios? -.>Nivel 0 = analfabeto.)
...y otras preguntas por el estilo.
2.- Olvídate en una primera etapa del aspecto que va a tener tu programa y de los controles que tienes que usar. Eso es empezar por el tejado. Primero una sólida, coherente y precisa estructura de datos. Luego los colorines. (Regla de oro número uno)
3.- Una vez que tengas el tipo de dato definido piensa muy bien el control que vas a usar. Es una absoluta aberración utilizar dos controles para manejar un sólo dato.
4.- Separa totalmente, o al menos en lo posible, el código de los datos. (¿Por qué rellenar los combos con código?¿por qué no escribirlo en tiempo de diseño en la propiedad list que te ofrece el ide? Mejor aún ¿Por qué no poner los datos de los combos en tablas y rellenarlos desde ellas? Así te ahorras trabajo en el futuro (regla de oro 2)
Por ejemplo: Rellenas por código del combo de Municipio y de Parroquia. ¿Y si la clínica se traslada o abre una sucursal en otro municipio dentro de cinco años? ¿Tendrán que buscarte y llamarte para que teclees las cadenas de caracteres y recompiles el programa...(a saber qué versión de
gambas manejas entonces)... o tendrán que tirar tu programa a la papelera? Si creas una tabla de municipios y tu formulario rellena el combo a partir de ella, sólo tienen que rellenarla con los nuevos y listo.
5.- Elimina todo el código innecesario que puedas (¿Qué sentido tiene asignar la propiedad .text a un montón de checkbox... que no tienen sitio en la pantalla para que ese texto se vea? Dedicas la friolera de 194 líneas de código a ello... y no sirve para nada) Ese código inútil te volverá loco dentro de un tiempo (reglas de oro 2 y 3)
6.- UTILIZA NOMBRES SIGNIFICATIVOS. El poquito esfuerzo que te cuesta poner a cada control su nombre, es algo que en depuraciones, rutinas, accesos a la base de datos, relleno de formularios, etc. etc. te va a volver loco (otra vez las reglas de oro 2 y 3).
Creo que es suficiente para empezar. Lee despacio lo que te pongo y estudia las diferencias de la base de datos que adjunto con la que tú manejas... y no te desanimes. Deberías ver el primer programa que yo hice. Para llorar comparado con el tuyo.
|
| Descripción: |
|
Descargar |
| Nombre del archivo: |
historias.sqlite.tar.gz |
| Tamaño: |
2.27 KB |
| Descargado: |
34 veces |
|
| Descripción: |
|
Descargar |
| Nombre del archivo: |
historias.sqlite.tar.gz |
| Tamaño: |
2.27 KB |
| Descargado: |
34 veces |
|
| Descripción: |
|
Descargar |
| Nombre del archivo: |
historias.sqlite.tar.gz |
| Tamaño: |
2.27 KB |
| Descargado: |
34 veces |
Foro 
Albacete
Montevideo
