Results 1 to 2 of 2
  1. #1
    AlexSalvadori is offline Novice
    Windows XP Access 2010 32bit
    Join Date
    Nov 2012
    Posts
    14

    Fields of Data! A best practice question

    First up I should say this post is for discussion/venting purposes only, so please don't fret use too much time thinking up awesome solutions (unless you want to!)

    Anyway, so I have been reconstructing a database for human resources. The one that came before me was barely functional and to be honest didn't make a lot of sense. Now, I am not a pro, I studied one module of access as a student and that was about two years ago, so I can't say for sure that it was wrong, but it just didn't sit right with me... It centered on the list of employees and their details (pretty common sense stuff) and apart from a few typos and duplicate fields this wasn't a big deal, but when you left that table you wandered into an entirely different logic.

    The other tables were things like gas stations, coal stations, qualifications and training records (Should have been reduced to two, no?) and within each of these there wasn't a 'name' field, like for the name of each qualification, instead there was: a foreign Key for the employees; and then a long list of data fields each named after a qualification/gas station etc, with a true/false data type, and from that there were some poorly strung together forms which just allowed you to click some check boxes to say whether the employees had those qualifications/ had been to those stations.



    Now that seems like bad practice to me, surely you're not supposed to use data fields for unique individual things like that?? Imagine if he had done it for the employees! And yet, doing it that way came with certain advantages. For instance, if I want to make a list of tick boxes that the user can simply click to say where they have been, it would take considerably more effort than the first guy would have used with the form wizard (since everything was its own field). But that's not the best part, it also flattened out the structure, allowing you to see all the relevant information for each employee in a singe horizontal line, for each 'field' was either true or false. This meant you could export the entire database into excel, something I am struggling to do better than even with what I think is a fairly advanced search query.

    Anyway, I am trying to put my finger on why that was the wrong way to do it, and yet I can't help but think with a little work, it would have been fine as it was...

    Any thoughts?

  2. #2
    orange's Avatar
    orange is offline Moderator
    Windows XP Access 2003
    Join Date
    Sep 2009
    Location
    Ottawa, Ontario, Canada; West Palm Beach FL
    Posts
    16,725
    The key to database is design. And design involves Tables and relationships between tables.
    To put your concerns into context.

    Relational Principles http://forums.aspfree.com/attachment...2&d=1201055452
    For
    Normalization
    Entity relationships
    Cardinality
    see https://www.youtube.com/playlist?lis...B3D90B4028B8A7

Please reply to this thread with any new information or opinions.

Similar Threads

  1. Replies: 4
    Last Post: 10-27-2012, 01:47 AM
  2. Best Practice for Access, Macro, SQL
    By seageath in forum Database Design
    Replies: 0
    Last Post: 02-27-2012, 09:34 PM
  3. Replies: 2
    Last Post: 02-07-2011, 01:11 PM
  4. Best practice?
    By thekruser in forum Queries
    Replies: 2
    Last Post: 09-20-2010, 09:41 AM
  5. Database Structure | Best Practice Question
    By davidson12 in forum Forms
    Replies: 0
    Last Post: 11-05-2009, 03:29 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Other Forums: Microsoft Office Forums