[CS-FSLUG] Church Management Software
Micah Yoder
yoderm at gmail.com
Tue Apr 8 09:39:00 CDT 2008
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. :)
More information about the Christiansource
mailing list