[CS-FSLUG] Church Management Software

[EnzoAeneas]

I think this situation lends itself to a data abstraction layer. So
that the backend storage can be maintained via pluggable components
rather than hard coded methodology, like interfaces/virtual classes
work in java, C#, and C++.

That way those who want to work on data storage can work on different
implementations, while others can push forward on the other parts
without worrying about how the data is stored. I would like to have
the flat file method developed first because it requires less setup to
debug,but in any case we will have to work out the API for the data
abstraction FIRST and this will need everyone's efforts.

On Mon, Apr 14, 2008 at 9:41 AM, Tim Young <Tim.Young at lightsys.org> wrote:
> Sorry I keep drifting in and out of this conversation. I occasionally
>  skim an email or two in this thread.
>
>  Amazingly enough, you are all right about the various technologies
>  (flat-file, database, web-based, etc.). Let me give you the brief
>  history of this topic when it comes to missions donor databases, which I
>  am in the middle of making one of...
>
>  A mission organization usually starts with something like
>  quicken/quickbooks for their finances (flat-file). After a year or
>  three, they find that they would like to keep more data, and that the
>  structure they have is not scalable, so they move to something else. For
>  quite a while they switched to a product called KMS, which was, at the
>  time everyone was switching to it, based on "Paradox." Paradox was a
>  database engine, but not a SQL database. Anyway, the main problem with
>  KMS was that it did not do enough reporting, and because it was not SQL,
>  they could not generate good enough reports with Crystal Reports (Nor
>  was there or could there be much of a web interface). So people started
>  migrating to SQL databases. Then, they have larger and larger systems
>  based on "audience."
>
>  In actuality, most of the transition from one system to another was done
>  because of two factors. Audience and amount of data.
>
>  While the primary audience is the one person, a flat-file system is the
>  quickest and cheapest way to go.
>  When you start getting into a multi-user scenario, the flat-file system
>  starts to break down somewhat. But it is the scope of reporting that
>  usually causes grief soonest. A truly flat-file system is difficult to
>  generate custom reports from. A good Linux admin can do wonders with
>  Grep and WC, but we do not want to make pastors learn that detail of
>  stuff to get at their data.
>  When you start getting into web-based systems (if people wanted to log
>  into their church to see what they have given for the year, and to give
>  gift online for their AWANA program) things get even more complex. To
>  keep data integrity, (as well as the fact that most of these systems
>  have a local and web interface) a database is usually required.
>
>  At LightSys, we are building using Centrallix (centrallix.sf.net), which
>  is a web front-end to a database (there is a LOT more to it than that,
>  but greater detail is not needed for this email). We realize that our
>  donor management system is overly complex for an organization which is
>  just starting out. But it will scale up for a great number of years,
>  where most of the other systems get replaced after just a few years.
>
>  I think the first thing you need to do is to decide the size of church
>  you are trying to target, and if you are looking at a single-user or
>  multiuser system. Then, decide about security (flat-file systems do not
>  have too much of that. Are you keeping credit cards info? How much
>  giving information needs to be secure?)
>
>  Then, who will be programming this? Robert (who I went to school with)
>  could put together a flat-file system very quickly. Micah Yoder (Who I
>  have attended ICCM with) is a pretty high-powered web programmer who
>  does a lot with SQL back-ends. But who else will be putting man-hours
>  into this, and what are their skill-sets?
>
>  The fact of the matter is that the technology you choose will not make
>  or break the system. It will dictate who gets to use it, but regardless
>  of which route you go, some will use it and some will not. Earlier I
>  mentioned the missions package KMA. KMA has recently gone opensource,
>  and one could consider them "competitors" for our Kardia (kardia.sf.net)
>  system. I do not look at it that way. What I have seen is that missions
>  need choices. Every mission does their data a different way, and so
>  there needs to be a wide variety in different types of tool. I would
>  imagine the same goes for church software. Don't expect that every
>  church, from the megachurch to the 15-person congregation will use your
>  software. But, what you would be doing is making an option where there
>  was none before.
>
>  Technology, like theology, can become a stumbling-block if we cannot
>  agree. Sometimes the decision will need to be made on criteria other
>  than pure technological merit, simply because we are not comparing
>  apples to apples.
>
>  My original point was lost somewhere in the rambling above. I basically
>  wanted to say that either flat-file or database would work. For me, it
>  would be more a matter of who you have who will be working on the
>  project. If you put most of your IO in one area, you can port it from
>  flat-file to database fairly easily later on if needed.
>
>  Hope my rambling was somewhat helpful,
>
>  - Tim Young
>
>
>
>  _______________________________________________
>  ChristianSource FSLUG mailing list
>  Christiansource at ofb.biz
>  http://cs.uninetsolutions.com
>