[CS-FSLUG] Church Management Software

[EnzoAeneas]

As compromise is to a database engine over CSV files. This allows the
db engine to use some methods to speed up access while leaving the
data transparent. Or even XML, but that may be slower depending on the
db engine.

With all databases, all data can be converted to text based
representation, usually SQL, and almost all can export to CSV with
separate SQL files to define the structure. The backups could be made
automatically if performance found to be too slow over text data
files.
Either way, this decision could made by the user at a later time,
because the eindividual programs could use text / xml for their
individual storage, but the integrated solution could use a database
to hold all of their data.

thoughts?

On Tue, Apr 8, 2008 at 9:16 PM, Robert Wohlfarth <rbwohlfarth at gmail.com> wrote:
> EnzoAeneas <enzoaeneas at gmail.com> wrote:
>
> > organization and faster access. Information in text files much be read
>  > in order, so searching is terribly slow and inefficient; storage of
>  > large quantities of data in this manner quickly becomes unweildly.
>  > Databases are not only able to deal with larger quantities of data,
>  > searching and find what is needed is far easier and faster (though not
>  [snip]
>
>  A lot of churches - especially the ones looking for free (cost)
>  software - have modest amounts of active data. I'm not sure if
>  performance is that much of a problem.
>
>  A database adds complexity. It must be managed, supported, etc... The
>  cost, in this case, isn't money. Volunteers face a steeper learning
>  curve.
>
>  Which issue would cause the most frustration for a user? Waiting an
>  extra five seconds once a week, or spending 40 hours repairing
>  corrupted binary data followed by another 20 hours catching up on
>  halted work?
>
>  Now all of that is theory. The programmer's first axiom: theory and
>  reality never match. How does this sound for a test?
>  1) Create 1,000 text files.
>         a) Each file contains 1,000 lines.
>         b) Each line contains 100 characters.
>  2) Measure the time to find the first line in the first file.
>  3) Measure the time to find the 500th line in the 500th file.
>  4) Measure the time to find the last line in the last file.
>  5) Run a series of 100 searches for random lines from random files.
>
>  Yes, I'm offering to write and run such a test. Though it may take a
>  few days... Is it realistic enough to cover the a bad or worst case?
>
>  --
>
> Robert Wohlfarth
>  rbwohlfarth at gmail.com
>
>
> It is done.  I am the Alpha and the Omega,
>  the Beginning and the End. -- Revelations 21:6
>
>  _______________________________________________
>
>
> ChristianSource FSLUG mailing list
>  Christiansource at ofb.biz
>  http://cs.uninetsolutions.com
>