I posted these questions to a listserv group, but nobody would give me
their opinion on them, or even attempt to give a single concrete
answer, I know this is long, but I would like ANYONE'S opinion.  To
me, the questions seem like common ones.  

        I am upgrading a small networked system (12 clients, 1 server,
1 workstation).  The clients store information real-time on the
server, and the information is accessed for report generation via the
workstation.
        Currently, the information is stored in a single database
table (I am using the Codebase dBase client-server package) and purged
at the customer's convenience or when the database is too large to
quickly generate reports.  The database table is only purged when the
customer is positive that the clients will not be accessing it.
        The upgrade will consist of adding scanning stations to the
network which will allow the stored information to be catagorized.
For example, clients will initially store the data in the HISTORY
database table on the server.  A barcode related to a particular item
in the HISTORY database will be scanned and the item needs to then be
related to INVENTORY instead of HISTORY.  

Here are my questions:

1. Should the item be physically removed from the HISTORY database
table and added to a second table called INVENTORY?  Or, should the
item merely be flagged as INVENTORY in the HISTORY database.
Resource-conservation-mindedness tells me to flag it, but the one
table can grow extremely large.        

2. This system can feasably be running 24/7 but the database
information needs to be purged periodically to decrease report
production time and to compact the database by removing
logically-deleted records.  The workstation will determine when to
purge the database based upon filesize, a scheduled time, or customer
request.  What is the best method for performing this without an
interruption on the client's end?  Maybe send a message to the clients
telling them to store information locally while the purge is being
performed, and then send a second message telling the clients that the
purge has finished?  

3. The user needs the ability to enter a production count on the
workstation.  For instance, 500 boxes of gimletsmarks, no more, no
less are to be produced.  When this production count has been reached,
a message will be displayed on the client's screen, telling the user
to stop production.  Any number of clients are being used to store
information on the server about each gimletsmark it produces.  The way
I envision it is having the workstation store the quantity of
gimletsmarks to be produced and the quantity remaining to be produced
on the server.  Before the client actually produces the gimletsmark,
it reads that count from the server to see if the total quantity has
been reached.  If the total has not been reached, it decrements the
total remaining and produces a gimletsmark. The database is
potentially hit twice, once to determine if the gimletsmark can be
produced, and a second time to relay information about the produced
gimletsmark.  Is this the most efficient way to perform this?

Thanks again for taking the time to read this.  Any input you may have
will be of great benefit.

M. Barton Hodges

I posted these questions to a listserv group, but nobody would give me
their opinion on them, or even attempt to give a single concrete
answer, I know this is long, but I would like ANYONE'S opinion.  To
me, the questions seem like common ones.  

        I am upgrading a small networked system (12 clients, 1 server,
1 workstation).  The clients store information real-time on the
server, and the information is accessed for report generation via the
workstation.
        Currently, the information is stored in a single database
table (I am using the Codebase dBase client-server package) and purged
at the customer's convenience or when the database is too large to
quickly generate reports.  The database table is only purged when the
customer is positive that the clients will not be accessing it.
        The upgrade will consist of adding scanning stations to the
network which will allow the stored information to be catagorized.
For example, clients will initially store the data in the HISTORY
database table on the server.  A barcode related to a particular item
in the HISTORY database will be scanned and the item needs to then be
related to INVENTORY instead of HISTORY.  

Here are my questions:

1. Should the item be physically removed from the HISTORY database
table and added to a second table called INVENTORY?  Or, should the
item merely be flagged as INVENTORY in the HISTORY database.
Resource-conservation-mindedness tells me to flag it, but the one
table can grow extremely large.        

2. This system can feasably be running 24/7 but the database
information needs to be purged periodically to decrease report
production time and to compact the database by removing
logically-deleted records.  The workstation will determine when to
purge the database based upon filesize, a scheduled time, or customer
request.  What is the best method for performing this without an
interruption on the client's end?  Maybe send a message to the clients
telling them to store information locally while the purge is being
performed, and then send a second message telling the clients that the
purge has finished?  

3. The user needs the ability to enter a production count on the
workstation.  For instance, 500 boxes of gimletsmarks, no more, no
less are to be produced.  When this production count has been reached,
a message will be displayed on the client's screen, telling the user
to stop production.  Any number of clients are being used to store
information on the server about each gimletsmark it produces.  The way
I envision it is having the workstation store the quantity of
gimletsmarks to be produced and the quantity remaining to be produced
on the server.  Before the client actually produces the gimletsmark,
it reads that count from the server to see if the total quantity has
been reached.  If the total has not been reached, it decrements the
total remaining and produces a gimletsmark. The database is
potentially hit twice, once to determine if the gimletsmark can be
produced, and a second time to relay information about the produced
gimletsmark.  Is this the most efficient way to perform this?

Thanks again for taking the time to read this.  Any input you may have
will be of great benefit.

M. Barton Hodges