[CS-FSLUG] Church Management Software

EnzoAeneas enzoaeneas at gmail.com
Tue Apr 8 15:02:48 CDT 2008


In the back of my mind, future development as well as integration by
knowledgeable church members pokes out as issues with that.
Though, as an open source project, that could be adapted. Also, we
could simply created an abstracted interface for data operations and
allow the data layer to use whatever strengths are available.

But I do agree that postgresql is the more robust choice, even if it
is slower than mysql on larger datasets.
Your arguments about lacking corporate control also make it a more
attractive choice.

Kevin

On Tue, Apr 8, 2008 at 10:39 AM, Micah Yoder <yoderm at gmail.com> wrote:
> 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. :)
>
>
>
>  _______________________________________________
>  ChristianSource FSLUG mailing list
>  Christiansource at ofb.biz
>  http://cs.uninetsolutions.com
>




More information about the Christiansource mailing list