[CS-FSLUG] Church Management Software

[Micah Yoder]

Josiah:

> Databases are strange beasts to the majority of the population.

Nevertheless they are *the* way to store data like this.  What happens
to data integrity if the system needs to update two or more files to
keep things consistent, then something happens and prevents it from
continuing after it does the first?  Any transactional ACID compliant
DB will prevent any problems there.

I believe it would add very little complexity for the user.  DB stuff
can be automated nicely.

David:

> Although the package may be called different things on each
distribution (or have slightly different defaults), increasing the
amount of effort required to package the program.

Maybe, but I don't think by much.  In any case, an early decision
needs to be made about what distro(s) this will target.  An
appropriate installer script could be made for each, but I suspect
they would be very similar.

>  There's also the
potential that someone else may already be using Postgres on the
machine - or may wish to do so in the future - which would again make
the configuration again more complicated.

I don't see why that would be a problem.  You keep everything related
to this project in its own database; anything else would use another
database.

> Or builds its own interface giving you a nicer feature set than the
original databases.  (It could translate something allowed by one
command in database software X to a series of commands to accomplish
the same thing in database software Y).

Could be done, but that does increase overall work.  Is that really
necessary here?  What do you gain?  Do small church pastors want to
have to choose between PostgreSQL and MySQL?

> Taking advantage of non-standard features makes the product more
fragile to change in the product which it uses.  I'm not sure if this
is still the case but at least in the past the Linux kernel could only
be built using the GNU compiler suite due to its use of extensions.  I
think that there may now be a patch for the kernel which allows it to
be built with the Intel C compiler (which, generally speaking, has a
better optimizer).  I consider this a deficiency of the Linux kernel,
not a positive feature.

Well no free DB system is 100% SQL compliant.  MySQL in particular is
quite far from it.  PostgreSQL aims for it, but is deficient in a few
documented areas.  SQLite doesn't even take type consistency seriously
by default IIRC (you can add strings and numbers & such).

Features of Postgres I think would be particularly beneficial:

* Schemas -- you can store data for different modules in different
table spaces, all in the same DB
* Stored procedures -- let the DB engine do the logical work

With a lot of abstraction, I think you'd lose that.