While it may not be immediately obvious, one of the principles of database management is that every piece of data that you collect and maintain has a cost. Whether that cost is time or money (or both) it should be carefully considered before you decide to include it.
If you are setting up a new installation without previous data, it should be fairly straight forward to consider how to input your data. If, on the other hand, you are migrating from another application you may want to invest a little time considering whether you really need the data you are planning to port over.
Principle: Don't Collect Data for Possible Future Uses
It is important to consider the data you will actually use rather than data that you think you might use. Sometimes it is hard to differentiate between these two but a little time carefully considering this question will save you some headaches later on.
For example, you may think that it is useful to keep track of the schools that your school aged children attend. One could imagine that this would be useful to have but in reality it is something you are not as likely to use unless you have a specific ministry geared to local schools (or home schoolers). It is probably safer, as a rule, to exclude data you are unsure about until you know for certain that you will need it. So, in this example, don't collect the data at first but if you launch a ministry to local schools make the collection of data from your families part of the ministry launch.
Another example might be wedding anniversary dates. It may seem to be very useful to have this data but for what purpose? Unless you are going to commit to a structured system of celebrating wedding anniversaries in the church you may be adding a cost (maintaining this data) that is not justified.
Principle: Is it Reasonable to Collect that Data?
Take, for example, birth dates. You will need to have birth dates for children in order to sort them for class registrations but do you need to collect adult birth dates? Say, for instance, you do celebrate birthdays. You run a query each month to prepare a list of names of people who have birthdays coming up so you can send a card. Will some people feel left out because they never receive a card? If they don't receive a card, is it because they haven't given their birthday, in which case are you going to publicly announce that the church sends out birthday wishes. What if everyone knows that you send birthday wishes, but you forget someone or you send to only a select group of people (say the seniors) leaving others feeling left out or neglected? And, what about those seniors. Some of them don't mind you knowing the day and month but they don't want you to know the year. Clearly, you will want to consider how you will collect and use this data before you collect it.
In the end you may choose to collect birth date data. However, there are other data fields that you may wish to more carefully scrutinize before adding it to your database.
ChurchInfo provides the capability of implementing custom fields for People and Families. If you plan to use custom fields consider carefully how these data will be used so that you can identify the implementation which will work best in the long run. Custom fields can be one of the following types:
Sometimes the best thing for you to do is to try adding custom fields so you can find out how they work (you can always delete them later). While this is a great way to learn how the program works, in the long run you will want to come to a final decision about which custom fields you will be using before populating your database.
In addition to custom fields, there are a number of elements in ChurchInfo which are user defined.