User Tools

Site Tools


create_a_data_plan

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

create_a_data_plan [2013/07/15 12:31] (current)
Line 1: Line 1:
 +======Create a Data Plan======
 +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. 
 +
 +====What Will You Really Use?====
 +**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. ​
 +
 +
 +
 +
 +====Custom Fields====
 +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: ​
 +
 +  ***True/​False**. Provides a checkbox which is for "​Yes"​ or "​No"​ fields (eg. valid driver'​s licence)
 +  ***Date**. Enter a date (eg. started attending our church). Note: this field provides a handy calendar to select a date and reminds the user of the correct date format (YYYY-MM-DD). ​
 +  ***Text Field (50 Char)**. Any text string up to 50 characters (eg. Denominational background)
 +  ***Text Field (100 Char)**. Any text string up to 100 characters (eg. view on the apocalypse)
 +  ***Text Field (long)**. Any text string more than 100 characters. (eg. notes on a pastoral visit)
 +  ***Year**. Inserts a year (eg. 2010) 
 +  ***Season**. Creates a drop down menu with the options: Winter, Spring, Summer, Fall. 
 +  ***Number**. A field for a number. (eg. Family registration number). ​ Note: you cannot include any non-number text in this box (eg. 57-245 or T561 would be rejected)
 +  ***Person from Group**. This adds the ability to add a field linked to a specific group of people, and select an individual from a drop down menu of this group. (eg. Small group accountability partner)
 +  ***Money**. Adds a field for financial data (eg. pledges)
 +  ***Phone Number**. Inserts additional phone numbers (eg. Unlisted cell phone)
 +  ***Drop Down Menu List**. Creates a drop down list with options you specify. (eg. City regions: Bronx, Brooklyn, Wall Street, Harlem, Uptown. Or Allergies: Latex, Peanuts, Dairy, Lint)
 +
 +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. ​
 +
 +
 +====User Defined Data====
 +In addition to custom fields, there are a number of elements in ChurchInfo which are user defined. ​
 +
 +===General Configuration Settings===
 +
 +===Properties===
 +
 +===Finances===
 +
 +===Groups===
 +
 +
 +
  
create_a_data_plan.txt ยท Last modified: 2013/07/15 12:31 (external edit)