Results 1 to 2 of 2

Thread: DB Checkup

  1. #1
    Join Date
    Aug 2007
    Port Macquarie, New South Wales, Australia

    Unanswered: DB Checkup

    Hello, could I please ask for advise on the design of my database. After reading a recent post called To lookup or not? I thought I would follow that lead and throw a few questions in here too. I would also like to refer to previous assistance sought which is contained in a thread called Merging which I will refer to later.

    The database I have relies on downloading data which is imported into tables based on a date range that I select from the external source of information. These txt files are imported on a daily basis and usually result in duplicated information due to the date ranges involved. So for example when I import people involvements I use the method of importing into the ImportPERINV table which stores duplicated info, then I run an update qry and append the data to the PersonTable which has the PK on CNI which is a unique number already created from the imported data from the external source. I then delete the content of the ImportPERINV table with a delete qry to enable new data to be imported the next day. These steps are contained in a macro.

    The individual people in PeopleTable are then linked to other tables to record certain information regarding their activities, previous events history and vehicles. The narrative table stores a memo to enable me to create news letters for distribution.

    Attached is a pic of the relationships to get an opinion before moving on to further questions. I'm sure there would be design faults so far, and I would appreciate any advise on a better design.

    Regards, Timmeh
    Attached Files Attached Files

  2. #2
    Join Date
    Nov 2007
    Adelaide, South Australia
    Well I'll start by saying enforce those relationships!!

    Isn't this already up and running? I'd be very reluctant to change anything if it's currently working.

    There are many things I'd want to change with that design, such as...

    * consistent naming - why not tblCategories etc
    * clear naming - wtf is Suburb2... what is CNI ... what is Client.Target etc
    * elaboration of ID field names - CategoryID instead of ID etc
    * enforce relationships ... for many reasons
    * ensure every table has a primary key

    ... but the nuances of your application might make it tricky to make such changes.
    Owner and Manager of
    CypherBYTE, Microsoft Access Development Specialists.
    Microsoft Access MCP.
    And all around nice guy!

    "Heck it's something understood by accountants ... so it can't be 'that' difficult..." -- Healdem
    "...teach a man to code and he'll be frustrated for life! " -- georgev

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts