Suggestions for a Membership Directory

[phuebs]

I'm working on a membership database/directory for our church.

I have created the main layout to be for a family. On a family's record it has Head of Household name, phone, work, etc. It also has the same for Spouse information. Then there are fields for the names of children.

I created a report that nicely puts each family into a "directory" with two columns of families per page. So far so good.

But now it gets more complicated. I want to have more detailed information for each person. For example, date of birth, date of joining the church, activities involved in, leadership experience, talents and gifts, whatever. How should I do that? Create a new layout with the names linked and related? Create a tab on the Families layout for each family member? I just don't really know.

OR....would you suggest that each individual member, no matter the age, be a record with all that detailed information? Then I could make summary reports that group them as families?! If I do that, how would I differentiate between families with the same last name? For example, how would I get the Dave Peterson children to be on Dave's family page and not the Vic Peterson children? And finally, if I do it that way, how would I get such a report, say called "Families", to properly report which person is the head of the household and which is the spouse?

Thanks for your help! I have good ideas in my head, I'm just not experienced enough to get it all figured out yet!

[bcooney]

I've been mulling this one over for a while, and need to ask, "What constitutes a family?"

For example, are two married sisters in the same family? They don't live together, and don't have the same last name. So, what is your criteria?

[phuebs]

A family would be those living in a house together, or those who would all receive one mailing.

I have just been going back and forth in my mind as to whether I should have each person be a record or each family be a record. I can't make up my mind. I just get hung up on doing a report for families or a church directory and getting the right people with the right family. How could I program it to know that Katie Smith is David Smith's daughter and not John Smith's daughter?----I'm looking for any advice here.

On a related note...I can't figure out how I would track church attendance for members, and then be able to do reports and searches for who hasn't been attending regularly, etc.

[comment]

Why not have both: a table of households and a related table of household members?

[phuebs]

That's not a bad idea. Would I just make a layout for each and link fields such as last name? Or how do you suggest I link a person's name in the families table to the individual person's record? I envision a first name field and a last name field. How would I make that whole name linked to a different layout or table?

[comment]

Give each household a unique HouseholdID - a number field with auto-entered serial number. Make a habit of having such field (a.k.a primary key) in EVERY table you create. In the People table, define another number field called HouseholdID - this will be the foreign key. Relate the two tables by matching the two HouseholdID fields.

[T-Square]

Having done something like this myself a few years back (and on a different platform altogether), I would like to point out that splitting out the members of household can make for some complex twists. On a practical, let's-print-mailing-labels-now level: How do you create address labels? Who would go on the label? What if their last names are the same? What if different? What if you want more members on the label? While such problems can be more or less easily worked out, they do need to be considered, and they do lend to the complexity of the solution. I agree that this is ultimately the way to go--especially given the OP's additional wish to track attendance (presumably on a member-by-member basis).

To track attendance, you'd need an additional table (maybe more) that links a person with a date. This table could be as simple as PersonID and Date, but you'd probably find other things to throw in (arrival time, service number, well-dressed or not, etc.).