Re: The agony of building an Application
- From: "Allen Browne" <AllenBrowne@xxxxxxxxxxxxxx>
- Date: Sun, 30 Jul 2006 00:22:36 +0800
Whew. Big question.
Firstly, there will be many here who can identify with your journey.
There are 2 ways to build a database:
a) Go and do a computer engineering degree. Lean all about normalization,
interface design, specification, project management, implentation, and
coding at a generic level. Then start at the practical level, trying to
apply all you have learned, until you finally gain some experience, learn
when to apply the rules and what is impractical or inefficient. As you gain
experience based on theory, you finally arrive at the place where you are
able to build a database.
b) Start messing with Access, and discover what you can do with it. Find out
the hard way that writing lots of code to do stuff is no substitute for
having the a normalized data structure. Try each of the 6 ways Access gives
you do do something, until you figure out which is the most efficent one.
Read the code the wizards create for you, and begin to mess with them until
to start to understand what they are doing. Get frustrated enough to ask
lots of questions and read lots of stuff until you begin to discover the
better solutions. Get frustrated enough with starting over so many times and
never coming to the end of the project ("Oh, can it do that too?") that you
eventually realize it is worth the effort to do a complete written
specification of what the project should achieve before you start.
With Access, I suspect that (b) is the route most people take. Whichever
approach you take, you finally end up with the meld of theory and experience
that you need to develop applications. Of course, you never stop learning,
as you discover new approaches, see what others are doing, and come to terms
with the versions.
Answers to your specific questions in-line. It assumes you have some theory
and experience.
--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.
"Sreedhar" <Sreedhar@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:E97CCB91-9CA3-4B8B-80D7-2994DEA74F1A@xxxxxxxxxxxxxxxx
How should I approach when I set out to build an Access Application ?
Start by writing a specification that defined what functionality the
database needs to provide, what data needs be stored, and what reports need
to be produced.
I find this document will be around 4000 words for a simple project, or
10000 or more for an involved one. This is terse (no wasted words) and not
too technical (the client who wants the database should be able to
understand it.)
How should I translate my objectives into what should be done with Access
?
During the specification process, I end up building a data structure that
provides everything that needs to come out of the database.
How to make sure I don't miss anything ? (and avoid the agony of doing it
all again)
While writing the spec and building the tables, constantly look for hidden
"manys", e.g. client needs many addresses (so separate address table)? Keep
it as simple as possible, but make sure the structure you have created will
handle every case. Ask questions and clarify until both you and the client
are certain that this will handle every case.
How to know what IS possible and NOT possible with Access ? (and avoid
that
"errr... I should have added this to my db!" feeling)
Don't be too hard on yourself: sounds like the process you have gone through
is giving you the very experiecen you need to ensure that you are able to
pick these.
But don't skip the specification! Would you try to build an ocean-going
yacht just by nailing boards together, without plans and engineering the
shape of the hull and applying the laws? Don't try to build the database
without the spec!
What is the reasonable time it takes to build a feature-rich Access db?
Depends on what's in in of course. By the time you write the spec, verify it
handles 100% of the cases, buid the data structure (tables with fields of
the correct data type, with the right properties and descriptions, indexes,
and relationships with referential integrity), construct the interface
(forms and subforms, with applied business rules, validation, code to the
helps complete the entries, and warnings for questionable entries, and
blocking of dangerous data), create the output (reports with their queries,
+ exports by file, upload, or email, and interface them with multiple
optional criteria applicable to each report), complete and debug the code,
write the documentation, construct the test data, complete the testing,
split the database, and constuct the installation, you are talking about a
couple of weeks work for the smallest project, or many months work for the
larger ones.
What are the best practices to do it ?
Wow, that's probably beyond this question, but stay tuned, read the
websites, and get some books.
Here's a free utility that will check your data structure of issue you may
have missed:
Database Issue Checker
at:
http://allenbrowne.com/AppIssueChecker.html
It cannot tell you that you should have used a different set of tables (the
Table Analyzer on the Tools menu can suggest that), or relationships, but it
can catch some of the common mistakes.
Hope that helps.
.
- Prev by Date: Re: strange errors when using Access objects
- Next by Date: Re: The agony of building an Application
- Previous by thread: Re: Msgbox Title
- Next by thread: Re: The agony of building an Application
- Index(es):
Relevant Pages
|
