Database Evaluation

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Does anyone know a good way to have your database evaluated? I've spent
countless hours refining my DB and I'm so close to having it the way I want,
I was wondering how I might go about having someone review it to make sure I
don't have any fatal flaws (I don't see) that would get messy.

Thanks.
 
Have you done any on-line searching? On what basis/criteria are you looking
to have your system evaluated?

Have you had users try using it? Have you watch how they use it and
answered their questions?

Are you concerned about a code review, to decrease the risk that your code
uses faulty logic, or are you more interested in design qualities, the UI,
and how your users with interact with it?

You might want to get a bit more specific about what you want evaluated.

Regards

Jeff Boyce
Microsoft Office/Access MVP
 
I'm most basically concerned with my table relationships. I'm pretty sure
everything is sound, I haven't written any large amount of code (I'm not very
good at it).

I guess I just need a user to beta test it for me. I need to set up user
accounts but I tried once and it got screwed up so I'm leary of trying that
again.
 
I do this frequently for customers. I create a map of all the tables in the
customer's database. The map shows each table in the database, all the
fields in each table, all the relationships between the tables and the type
of each relationship. The map is generally arranged to show the flow of data
through the database. While I construct the map, I make note of any
suggestions I have. In the end I turn over the map to the customer with a
list of recommendations if I have any. I might note that from you saying you
haven't written any large amount of code is a good sign that the design of
your tables is decent. Where there is not a well designed set of tables
there usually is a relatively large amount of code to compensate.

PC Datasheet
Providing Customers A Resource For Help With Access, Excel And Word
Applications
(e-mail address removed)
 
I'm most basically concerned with my table relationships. I'm pretty sure
everything is sound, I haven't written any large amount of code (I'm not very
good at it).

I guess I just need a user to beta test it for me. I need to set up user
accounts but I tried once and it got screwed up so I'm leary of trying that
again.
Click to expand...

To the extent you can share, what is the expected use of your
database? Is it "business-critical" (meaning if something goes wrong,
you or your organization will feel a significant impact)? The level
of effort you place into testing your solution should be driven in
part by that answer.

As far as how you evaluate a DB in general, Jeff is spot on that you
should have users try it (and ideally, one of them try to do things to
"break" it by testing for error conditions you haven't anticipated).
For example, if you are most worried about your table relationships,
the user would work up a few test case scenarios to see what level of
referential integrity exists. Then you would want to compare that to
your requirements (i.e., what you are expecting/wanting your solution
to do).

Brandon Smith-Daigle
http://accesspro.blogspot.com (access tips for non-programmers)
 
I'm most basically concerned with my table relationships. I'm pretty sure
everything is sound, I haven't written any large amount of code (I'm not very
good at it).

I guess I just need a user to beta test it for me. I need to set up user
accounts but I tried once and it got screwed up so I'm leary of trying that
again.
Click to expand...

To the extent you can share, what is the expected use of your
database? Is it "business-critical" (meaning if something goes wrong,
you or your organization will feel a significant impact)? The level
of effort you place into testing your solution should be driven in
part by that answer.

As far as how you evaluate a DB in general, Jeff is spot on that you
should have users try it (and ideally, one of them try to do things to
"break" it by testing for error conditions you haven't anticipated).
For example, if you are most worried about your table relationships,
the user would work up a few test case scenarios to see what level of
referential integrity exists. Then you would want to compare that to
your requirements (i.e., what you are expecting/wanting your solution
to do).

Brandon Smith-Daigle
http://accesspro.blogspot.com (access tips for non-programmers)
 
Steve said:
Where there is not a well designed set of tables there usually is a
relatively large amount of code to compensate.
Click to expand...

Congrats Steve, that is by far the biggest piece of drivel you've posted so
far.
 
Well I'm going to be old hat 'cause I'm an auld mannie.

Firstly I'll say a User to test your stuff is about the most important
person you can get. (I think all the other posts say the same in their own
way.) Even more important is that the User be INTERESTED in getting the
system to provide what is needeed. Also it is not just you, it's us checking
things out.

Back to checking/evaluating your system. (I would like input from the other
respondants, as none mentioned it.) Have you already tried the inbuilt
Analyser (it may be a z rather than an s in the spelling) under tools
(forgive me if it is not available in Acces 2007). I have used it frequently,
and found it worth while. You can choose to implement or ignore the
recommendations fom the analyser, but it is an insight.

Most other ways will involve using using a Steve (look at some of the other
posts) or the like.

Hope this helps

AuldMannie
 
Back
Top