Best practices for database application design

[Jennifer Murphy]

Hi,

I am a new member. I've fiddled around with database software for many years, but never got serious about learning how to use this powerful tool well or correctly. I'm never going to be a professional database programmer, but I do have a number of personal applications that would be much better implemented in a database than in Excel or Word, as I am doing now.

I have Office 2007 with Access.

My first question has to do with proper design procedures. Is this a good way to approach a new application:

1. Decide what functions the application will perform. Make a list of the tasks that I will want it to be able to complete.
2. Lay out the tables. Identify all of the data elements and organize them into non-redundant (normalized) tables.
3. Design the forms.
4. Start coding.

Comments?

[ishatoo]

Morning Jennifer...You got it with the first 2 steps. But before you start creating your forms you will need to create queries. The query is a way of retrieving information directly from your table using a specific criteria. The criteria is used to filter your information. For example, you create 2 tables (Customers and Orders), you can then use a query to filter the information to the Orders place on a specific date. You will then use them to create your forms and reports. After that you can start coding on the forms and reports.

Here is a link from MS Office to get you started:

http://office.microsoft.com/en-us/ac...001224247.aspx

[Jennifer Murphy]

OK, thanks. I'll look into that.

[Allan Murphy]

Jennifer

Although these are your own personal database may I suggest that get in the habit of having proper documentation. I make this suggestion as some time in the future you maybe asked to do a database for a friend(client) and you find that having the proper documentation will assist the client in determining their needs and you in understanding their needs.

Search "System Development Life Cycle" for some ideas.
For the client you will need a High Level Business Requirements followed by Functional Specification and finally Design
Specification. The High Level Business Requirements is an overview of the project. The Functional Specification breaks the overall projects in functions. The Design Specification is used by the programmer to design the screens, tables etc.

I am not a professional programmer, but with my current project for a friend I have created a High Level Business Requirements and a Design Specification based on the client's vision of the screen layouts. The original Design Specification for each screen layout was based on the client's layout. Each Design Specification was changed with the client's approval as a better user interface was developed.

Finally, documentation comes in handy as it is a reference point when you need to make changes to the database etc.

I can send a copy to you if you wish.