well, you've obviously done a lot of design work, so i'd start by compacting
the database, if you haven't already been doing that regularly during
development.
then i might review my tables' fields to make sure the data types are
optimized. for instance, if you're using Double field size for number fields
that will hold only whole numbers, you can save space by changing the field
size to Long Integer. and review the "whole number" field size assignments
too. if you have a number field where the highest value will *never* be more
than 255, but the field size is Long Integer or Integer, there again you can
save space by changing the field size to Byte. ditto values that will never
be larger than Integer field size, make sure the field size is Integer, not
Long Integer. NOTE: back up your database before changing data types or
field sizes, just to be safe.
next, i'd split the database, because you've got a fair amount of space
eaten up with the user interface objects (everything except the tables).
also, if your design incorporates "archive" tables to hold obsolete data,
you can consider moving those tables into a separate database. since your
frontend (user interface) is already separate from the backend (tables), it
doesn't matter if the linked tables in the frontend are coming from one
backend database, or multiple backend databases.
having done all that, and compacting as you go, you're starting with as
small a backend database as possible. if you regularly add/delete/edit
records, you should regularly compact the db, to keep it as small as
possible. now, having said all that, 70 mb is pretty small, as compared to 2
GB. depending on just how "gradually" you expect the size of the data file
to increase, it may be quite some time before you have to consider upsizing
for space purposes.
hth
