On Wed, Sep 14, 2005 at 06:33:53PM -0400, Timothy Miller wrote:
> I think you can just do something like how you do an auto-increment on
> an index number for a table key. The main live database is the common
> thread that everything has to go through, and you can get it to give
> you a unique number for every request. That doesn't let the user pick
> then at will, though.
The user must be able to pick the root number at will, subject to
uniqueness. That's a fundamental requirement of the proposed part numbering
system, and you'll see why when you have a chance to absorb the description
of how it's constructed and why.
The auto-incremented index could be a unique transaction number,
though. That might have uses of its own in integrity checking. Humans
wouldn't be interested in it, though, and a script that formats the raw log
for display could ignore that field.
> > All this still theoretical of course, because a mirrorred SVN repository
> > will
> > easily do for the near future at least.
>
> Maybe we could replace the database with a PHP script that can commit
> to the SVN repository. :)
>
> But I like the idea of using a database for live activity, as long as
> there are facilities to mirror it elsewhere on the fly.
The reason I hesitated to suggest just using an off-the-shelf data
base system is that I've seen too many cases of lost and corrupted records
in inventory systems, even those running on high-end IBM data bases. They
seem to be designed to stay up-to-date with a fast-changing business, but
not necessarily to prevent permanent loss of the record of a single event,
if it doesn't get detected before the oldest backup tape is recycled.
So some kind of data base might still be the best solution, but its
fundamental design would have to be examined to determine whether it has the
characteristics this type of application requires. If not, it might be
possible to add airtight historical integrity checking and recovery to
something that comes close. We seem to have some talented CS people on the
list, who can think this through from the fundamentals.
A few thoughts...
If the log system generates a unique transaction number for every
log entry, that can be the basis of a routine that checks for missing
transactions at every commit. Then the system would always know how many
entries there had been since the beginning, and if a transaction were
missing, it would immediately determine which one and display an error
message.
If CRCs or crypto signatures are used, they could be done one per
log entry rather than one per DBMS table. That would limit the uncertainty
and recovery work if an entry became corrupted.
Another use for a sequential transaction number is that it could be
used to completely eliminate any editing of number log entries. Every
transaction, once committed, would be immutable. Instead, a later entry
would be written for the same root number, assigning a higher transaction
number. The latest entry would be the current one, but all would be shown
in a display screen or printout, giving a complete historical record.
Screens and printouts should be sorted by root number, and by transaction
number within the same root number.
If we have any CD-burning experts, they might like to comment on the
idea of using multi-session writing for archival backup. The master
off-line backup might be on a CD-R. Periodically, the volume could be
loaded, and all transactions not previously backed up could be written in a
new session. Older sessions would inherently be read-only, so that once a
session is written, it's forever immune to software bugs, crashes, hardware
failures, or any other cause outside of media deterioration itself. This
gives it most of the physical durability of a handwritten paper log.
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
