|
Imagine the scenario... someone
in the company (probably without a background in database design) discovered
Access. Access is easy to get into and within a couple on months they have
created a database which stores customer details, orders, invoices and an ever
growing list of other information. In fact, it's so useful that half the company
are using it by now.
Then the problems start. The
tables were added piecemeal and aren't normalized or related. As the amount of
data grows from a few hundred records to tens of thousands the database slows
down so much that people are queuing at the coffee machine while their reports
run. The design use macros to link it all together and the designer can’t know
for sure which ones are actually used and which are just dead wood, so he is
cautious about changing anything in case it all stops working. Without naming
conventions it's getting really hard to tell the difference between tables,
queries, sub-queries, forms, sub-forms ...
Further
development stops. The designer can't risk making any more changes because the
database is mission critical to the company and the risk is too great. Meanwhile
the database keeps slowing down...
If this scenario sounds familiar we may be
able to help.
Key Benefits
- Convert your "liability"
into an asset
- Produce a maintainable design which may be extended
further
- Recover scaleable performance
Capabilities
We have the tools and experience to take almost any
Access database and convert it into a design with which the company
may safely move forward. In some cases you may want to keep only the data,
in which case we would work with you to specify a totally new front-end
application into which the data may be imported. In other cases you may be
happy with the front-end as it is stands but simply require it to be
converted from an "organic creation" into a well-engineered design!
We would review your database and recommend some or all of
the following, depending what we find in the existing design and the extent of
the problems you are experiencing.
- Clear out the dead wood
- We can eliminate all dead wood from your existing
design by mapping where each and every object and piece of code is
used. Anything which is not used is out! This process may easily halve
the number of objects and size of your database.
- Convert to front-end / back-end
- We would automatically divide your application into a
front-end (application) and back-end (data). There are many benefits
and there is no real downside.
- Convert macros to visual basic
- Macros are fine for very small databases. For larger
databases they become a maintenance nightmare. On the plus side, they are easy to convert into visual
basic which is a delight to maintain, runs faster and is supported by
some excellent tools and debugging aids.
- Add a centralized error handler
- In every procedure we add a one-line call to a global
error handler. This can be something simple which just displays an
error message, through to a full blown error logger. The error handler
will speed up further development and debugging and provide quality
assurance of the final result.
- Normalize and relate the back-end data tables
- The table structure underlies everything else in the
database and performance and data integrity are likely to be poor if
the table structure has not been carefully designed. A redesign of the
table schema in a mature database is a tough call but the payback can
be huge.
- Apply naming conventions
- There are standard ways of naming objects in a
database which make it far easier to understand. They help the
designer to identify object types and to group related objects. This
helps not only the original designer but anyone else taking over down
the line.
| 
