[dba-Tech] database

How intuitive. You have obviously done this before.

That is exactly what is happening now. Lookup tables for customers and
inventory are the feeder tables and the rest is batched through back ground
processes. Real-time accounting is a little more tricky but a temp record is
created and any changes saved as the client moves from invoice to invoice.
After a few minutes of inactive the station starts a re-balancing
process...posting and retrieving. 

Even the invoice printing is optimized as the invoice layout is pushed into
memory and then printed directly to the hardware.

It takes a few seconds for an invoice transaction to ripple across the
network. Only active invoices are local and all posted and completed records
are moved to backup "posted" tables. 

Right now there is only a two stage process but today the third stage will
be tested...the five-years, moving window through the over-night
transactions. 

Because the application is not tightly integrated there is always the chance
of data corruption and so a number of copies of data are CRCed and validated
at various intervals. If corrupt data is discovered, the data is retrieved
and the affected tables refreshed from the latest good-copy. This all goes
on in the back-ground and the users are never aware...but I automatically
receive an over-night email listing all suspect and real errors and
therefore can, mostly resolve serious issues before the stores open in the
morning. The process obviously works as I have only lost three invoices in
over twenty years...caused by errors I believe I would catch today. 

This whole system was created before more and more powerful hardware was
used to compensate for bad programming and therefore its foot-print is very
small.
 
Jim

-----Original Message-----
From: dba-tech-bounces at databaseadvisors.com
[mailto:dba-tech-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller
Sent: Saturday, January 26, 2013 1:10 PM
To: Discussion of Hardware and Software issues
Subject: Re: [dba-Tech] database

Jim,

Given that it's a POS system, then I would want to distinguish its two
primary functions: data-entry and data-accumulation (for want of a better
term). That in turn suggests a pair of identical-looking databases, one
dedicated to each purpose. Given that performance is the priority in the
data-entry aspect of a POS system, there's almost no reason to lug about a
lot of data. Transactions could be recorded into an almost-empty database
(save the lookup tables, which obviously would not be empty, but also would
seldom be updated). Then some sort of replication process would copy
yesterday's sales to the larger database, against which almost all reports
would be executed. This could even be a three-stage process, a db for
Today's Sales, This Month's Sales, and everything older.

A.
_______________________________________________
dba-Tech mailing list
dba-Tech at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-tech
Website: http://www.databaseadvisors.com