Re: Informáticos e Ingenieros de Sistemas!!!!!
igorcb dijo:
Sólo un detalle, yo vivo en Santa Cruz, Bolivia, no en La Paz jejeje
Bueno, entrando en materia Para mi es básico en una iglesia que se mantenga una base de datos de las personas, con sus datos personales, como ser :
Nombre
Apellidos
Dirección
Ciudad
EdoOProv
CódPostal
Región
País o región
TeléfonoTrabajo
ExtensiónTrabajo
TeléfonoCasa
TeléfonoMóvil
NúmFax
Dirección
NomCorreoElectrónico
Fecha nacimiento
ReferidoPor
Fotografía
Notas
EstadoCivil
NombreCónyuge
InteresesCónyuges
NombresNiños
CiudadNatal
InteresesContactos
Aficiones
TemasSalud
Ocupación
Luego las especializaciones:
Miembro (Fecha de bautismo, Fecha de conversión, Ministerios, etc)
Siervo (Fecha Inicio de servicio, Servicio, Responsabilidades, Dones, Disponibilidad, Sevicio pago o no) Acá se registraría pastores, diáconos, músicos, ancianos, etc
Contacto (Tipo, organización, referencia ) Otro tipo de personas como miembros de otras iglesias, visitas, proveedores de servicios, etc
Conseguiré alguna herramienta Case y trataré de hacer un diagrama de clases
Igor, seguro que estas hablando de varias tablas con integridad referencial.
Por cierto, recomendé mysql, y sigo recomendandola por ser open source, freeware y muy sencilla. Si usamos una base de datos muy compleja podemos tener problemas, porque en la sencillez hay mas posibilidades que mas participen.
Pero quiero advertir de un problema con mysql: que no tiene integridad referncial (sin claves foráneas). Así que la integridad refeencial habrá que introducirla por programación.
Hay otra base de datos, que se llama Postgrest, que es open source y freeware, y tiene nivel como Oracle. Esta incluye características de orientaciòn a objetos, integridad referencial y lo que que quieras (pero lamentablemente no te hace el desayuno jejeje). Pero el problema es que no es tan sencilla como mysql.
En cuanto oracle, hay una versión freeware pero con la condición de que solo se puede usar para aplicaciones sin ánimo de lucro y no es open source (que yo sepa).
Mi apuesta es mysql, la cual es multiplataforma (aunque Postgrest también lo es), y muy, muy sencilla.
En cuanto a la lista de atributos de la BBDD que promones, me parece muy bien, pero se tendría que decidir sobre el universo de personas que serán incluídos en la BBDD de una iglesia.
Yo pondría en la BBDD no solamente los miembros, sino también los conjuges y los hijos de los mismos. Y hemos de tener en cuenta que los conjuges o los hijos quizás no sean miembros, o ni siquiera creyentes, o noi siquiera asistentes.
¿Porque incluir esposas y hijos? porque para hacer listas de familias para orar por ellas son necesarios sus nombres. Es que en mi iglesia tenemos ua lista por familias paa orar por algunas de ellas cada semana ...
Así que propongo que la BBDD tenga una tabla de personas, pero también una tabla de familias, y una tabla persona-famila que las enlace. Quizás Igor ya lo has pensado, pero lo apunto por si acaso.
En cuanto teléfonos i e-mails, deberían estar en tabla aparte (quizás también lo has pensado), ya que no debemos limitar el número de teléfonos ni el número de direcciones electrónicas que pueda tener una persona. Lo normal es tener una sola dirección electrónica y varios telçéfonos. Pero yo no pondría límites, por ellos es mejor que sean tablas y no que estén incluidos en la tabla de personas. Bueno supongo que esto lo has pensado, y quizás estoy escribiendo mas de la cuenta, disculpa jejeje.
Y si incluimos miembros y familiares, es necesario identificar quienes son miembros, quienes exmiembros, y quienes nunca han sido miembros (como hijos que aún no se han bautizados), bien con un campo de "vinculación" o bien por período de vinculación (FechaInicioVinculación, MotivoInicioVinculación, FechaFinVinculación, MotivoFinVinculación). En este caso los exmiembros tendran FechaFinVinculación que puede ser una fecha concreta o simplemente la fecha en que se informó que la persona ya no es miembro. Y si la persona aún no es miembro, se puede no informar la FechaInicioVinculación, por ejemplo. Etc etc...
En cuanto al tema de metodología, creo que eres partidario del método clásico de "en cascada", o sea AnálisisFuncional + AnálisisOrgánico + Programación. Pero te propongo que hagas fases. Fase1, fase2, fase3, ...
Y en cada fase el objetivo es añadir 1 o varias funcionalidades para obetener un producto UTIL. Y dentro de cada fase, puedes usar tu método favorito ("en cascada" por ejemplo). La ventaja de las fases es que una vez acabas el análisis de la fase1 (p.e.) continuas con el análisis de la fase2 mientras los programadores están programando las fase1. De esta manera se hace un trabajo muy fluido y el proyecto se acaba antes. Pero si quieres hacer analisis total, los programadores estarán cruzados de brazos. El inconveniente de las fases es que puede suceder que en alguna fase tengas que asumir porner un poco patas arriba la BBDD. Pero creo que vale la pena asumirlo. Lo que te cuento hay gurús del análisis que lo proponen y se está poniendo en práctica con éxito. Aunque también hay otros gurús del análisis que se resisten y se echan las manos a la cabeza y defienden el sistema ya conocido de "en cascada". Eso si, el metodo co fases requiere asumir cambios bruscos en alguna fase. Pero si se hacen las cosas con vistas, hay pocos desperdicios.
Si se hacen las 3 capas, no necesariamente las 3 capas se tienen que hacer con un solo lenguaje. Se puede hacer una capa con PHP y otra con Java, ya que PHP puede usar clases de java, si no estoy mal informado. Si yo programase con vosotros (ahora no estoy disponible durante los próximos meses) trabajaría en una capa de java. No se si es buena la idea de emplear PHP y Java en lugar de Java. La ventaja de usar PHP y Java es que tendrías mas programadores disponible. Pero la desventaja es que no habrá nadie o casi nadie que sepa entender toda la programación y eso es un peligro. Eso si, sería una locura que en una sola capa hallan clases PHP y clases Java, pero si sería razonable que cada capa pueda tener su lenguaje de programación.
