[CS-FSLUG] Church Management Software

EnzoAeneas enzoaeneas at gmail.com
Tue Apr 8 22:12:10 CDT 2008


"The programmer's first axiom: theory and
reality never match."

So true.

actually, text processing always depends on the tool as assembler
could blow away sequential access with fixed-sized records,
as could C for that matter, but perl is much better for parsing out
tokens based on context.
But when it comes to parsing XML based on xml-based contexts, saxon
(java) may be easier to program for intricate cases, but perl is still
probably faster at stright processing.

So I guess it depends on context.

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
>




More information about the Christiansource mailing list