Results 1 to 4 of 4
  1. #1
    Join Date
    Sep 2004
    Raleigh, NC

    Unanswered: Advice on managing tables

    I'm interested in creating a database for work that 26 individual branches will use. (The backend will reside on a corporate server and I suppose I'll link to it from local frontends) My question is this:

    Assuming each branch has certain information associated with, do I store data all in one big table and query/sort based on the branch? - OR - Do I create individual tables for each branches data and link only to those tables? * Each branch should also be able to explore information from all other branches though...

    Example: Each branch has it's own personnel working within it. Do I create a single table ("tblPersonnel") in the backend and then sort by the branch to display the relevant information to the user? - OR - Do I create several tables ("tblPersonnel_A", "tblPersonnel_B" etc) where each branch would have it's own personnel table? Is there a right or wrong answer to this question?

  2. #2
    Join Date
    Apr 2006
    as long as all these information will be used by all clients, you should avoid creating multiple tables for similar data/information


    if i were in branch A and i need to create a new employee record, what form opens up for me, and what table should be behind it?

    i guess the point is if you use tblPersonnels as in the example, you are forced to maintain probably multiple configurations of your front end to cater to all clients, or perhaps add extra routines/coding to cater to these situations...
    and that's really unnecessary...
    Only quitters quit!

  3. #3
    Join Date
    Nov 2004
    out on a limb
    Provided Answers: 59
    consider doing both
    agree that shared data MUST be on the central server, however you could store local data (eg local configuration, local products on a local server).

    depending on how volatile your central (shared) data is you could consider moving some of that to the local machines as well (for example if you have a customer master database run centrally on a separate systrem you could import that customer table to either)... If you import it to the branches it may give you a perfomance benefit ... effectively you are cacheign data locally so JET has less work to do up and down the wire. This stratgey will not be appropriate if you are using a server back end to store the data, which if you are planning on 'feeding' 25 branches then Id guess you must be either planning, or need, to use a server backend
    I'd rather be riding on the Tiger 800 or the Norton

  4. #4
    Join Date
    Oct 2002
    Leicester - UK
    I'd advise the 1 table approach it's easier to control and manage. and it's always easier to screen data from a single table than to merge data from lots of tables.
    Definition of a Beginner, Someone who doesn't know the rules.

    Definition of an Expert, Someone who knows when to ignore the rules.

Posting Permissions

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