Solved Access Table for Defect Tracking
- Thread starter cyliyu
- Start date
Gasman
Enthusiastic Amateur
- Local time
- Today, 07:20
- Joined
- Sep 21, 2011
- Messages
- 16,612
I good start would be to try and understand Normalization.?
This is from a member's link (Minty) http://rogersaccessblog.blogspot.com/2017/03/what-is-normalization-part-i.html
What you want out of the DB sort of defines how it will be built.? Even if you bought a defects package in Access, it is likely you would need to tailor it to what you need.? It would just give you a head start.
Try googling for some? https://www.google.com/search?q=acc....69i57j0l2.20730j0j7&sourceid=chrome&ie=UTF-8
This is from a member's link (Minty) http://rogersaccessblog.blogspot.com/2017/03/what-is-normalization-part-i.html
What you want out of the DB sort of defines how it will be built.? Even if you bought a defects package in Access, it is likely you would need to tailor it to what you need.? It would just give you a head start.
Try googling for some? https://www.google.com/search?q=acc....69i57j0l2.20730j0j7&sourceid=chrome&ie=UTF-8
- Local time
- Today, 07:20
- Joined
- Feb 19, 2013
- Messages
- 17,411
every application is different so can't be specific. You do need to understand and apply normalisation rules and also understand relationships and how they work. And strongly recommend don't use lookups, multivalue or calculated fields in tables - they look 'useful' but in practice will lead to tears in anything but the simplest of applications.
Always worthwhile before even opening access to get a piece of paper (or use stickies on a whiteboard or wall) to sketch out your design, group related data together in a way that does not require the data to be repeated. and draw lines between the data that will be used to create a relationship. For example a sales invoice has a customer, invoice header and invoice lines (that's 3 tables). Invoice lines might have products whilst customers might have multiple addresses - which are a couple more.
There are 3 types of relationship one to one, one to many and many to many. The first is rarely used, the last requires a joining table.
Give field names that are meaningful to the datatype (is ABC123 a number or a code?) and consistent with the whole application, not just the table (ID? ID of what?, Date? Date of what?)). Also don't uses spaces, non-alphanumeric characters or use names that are reserved (such as date, desc, description, name) - it's personal preference but I use camel style (customerName, productCode)
Always worthwhile before even opening access to get a piece of paper (or use stickies on a whiteboard or wall) to sketch out your design, group related data together in a way that does not require the data to be repeated. and draw lines between the data that will be used to create a relationship. For example a sales invoice has a customer, invoice header and invoice lines (that's 3 tables). Invoice lines might have products whilst customers might have multiple addresses - which are a couple more.
There are 3 types of relationship one to one, one to many and many to many. The first is rarely used, the last requires a joining table.
Give field names that are meaningful to the datatype (is ABC123 a number or a code?) and consistent with the whole application, not just the table (ID? ID of what?, Date? Date of what?)). Also don't uses spaces, non-alphanumeric characters or use names that are reserved (such as date, desc, description, name) - it's personal preference but I use camel style (customerName, productCode)
Similar threads
