On Fri, 2002-02-15 at 09:08, Corey W. Gibbs wrote:
> What's the application? How big are your
> databases? Are you using Visual Basic or C to connect to it through ODBC
> or are you using a Web interface?
My company is using postgres in several related applications in retail
point of sale and inventory management.
Our point of sale system, OpenCheckout, uses postgres as its backend.
The size of the databases varies according to the retail install, but
for a recent trade show demo we loaded up a craft and hobby industry
database of UPC codes and item information that contained about 800,000
items. With that size database, random lookups on an indexed field
(the UPC code) were reasonably quick. We haven't extensively tested
with large numbers of users but our early results are positive.
We are also using postgres as a server for a fixed asset tracking system
we are working on. Inventory management and computer service people
with wireless handhelds (compaq ipaqs running Linux) connect to a
postgres server to get network configuration, service history, and
hardware information from computers, switches, and even network jack
plates keyed on a barcoded property tag. The user just scans the tag
with the integrated barcode scanner and can view or edit lots of
different kinds of information.
And we use the same handheld system to interface to our point of sale
inventory database, for receiving people in the warehouse to scan
incoming items into the database or for reordering people wandering the
aisles of the store. Postgres lets us tie all this together pretty
easily.
Sad to say :) we use SQLite when we have to go off the network and
operate disconnected with the handheld units. The ipaq just doesn't
have enough horsepower and storage space (32M of non-volatile storage,
64M RAM) to run postgres locally plus all our software. We keep an
audit trail table and replay it when we can get wireless access to the
postgres server again.
We access the database in a variety of ways. Most of our tools are
written in Scheme and use a Scheme wrapper for the libpq libraries. For
the accounting components we use a middleware layer based on the
'gnucash' accounting engine, which provides a uniform financial
transaction API. The actual POS front end is written in Java (so it can
use the JavaPOS point of sale hardware driver standard) and gets many of
its configuration parameters from the same database using JDBC.
Hope this helps
Bill Gribble
