[CS-FSLUG] Church Management Software

[Micah Yoder]

On Mon, Apr 7, 2008 at 3:01 PM, EnzoAeneas <enzoaeneas at gmail.com> wrote:
> Actually, a full DATA abstraction layer (all data) would be better.

>  But alas we need to get some working modules going.
>  In general, I am the first to push good design first, but I think that
>  if we are cognizant of the eventual integration of everything, we can
>  create modules that will not require too many changes to allow
>  integration.

Abstraction layers can be OK ..... but they can also make things crazy
complex AND make it hard to take advantage of specific features of
your DB engine.

I like to advocate simply using PostgreSQL and forget about
abstraction, because:
* It has as many features as any open source engine
* It has a VERY strong community and is NOT going away
* It is multi-platform
* It has a rich feature set ... transactions, ACID, schemas, boatloads
of built in types and functions, storable procedures in many
languages, now full-text search
* It has a BSD license, allowing it to be used with software of any license
* It is not tied to the whims of a single company
* It has a very sane user/role/permission structure (unlike others ...
*cough* MySQL *cough*)

In other words, it has everything anyone could hope for.  An
abstraction layer would turn the DB into a dumb storage engine, while
PostgreSQL is capable of much more than that.  Making full use of its
functionality could potentially save quite a bit of work.

If we produce a suite of software that someone would want to install,
they would simply install its prerequisites -- which we could define
as PostgreSQL.  I don't think the pastor of a small church would care
to have to chose engines, especially if PG were automatically set up
in the install process. :)