Table Design

  • Hello,

    I have a slight dilemma.   Currently, data is entered into a grid in my VB application using fields and formats that are specific to our in-house Version Control System.   We are now moving to a new Version Control System that uses different fields and formats.   The grid in my application will be changed to allow users to enter data using the new field formats, but historical information must also still be shown.

    I expect that the old system and the new system will have some of the same fields in common.  But a problem with using the existing table is that some of the columns in it will always be empty from this point forward.  They only need to be there because they contain the historical data.  

    A suggestion that was made was to create a new table containing just the new fields and the primary key from the original table (this would really only be 3 fields in total).  Then a VIEW could be created across the two tables that would represent the new data schema.  I have never used views before.  Isn't the space still wasted in the original table for those fields that are never used again?  Should I follow this recommendation or is there something better that I could do?

    Thx.

  • That sounds like a very good suggestion. 

     

    If you want to keep historic data, no space is wasted in the "old" table; you want those records and no new records will be inserted into that table. 

     

    Views are not tables, so no space is wasted there either.  A View is like a table in its presentation, but all it really is a representation of fields composing a table - which is compiled and quickly generated. 

     

    If you are planning on using the View itself for Updates and Inserts (as well as Deletions) I would highly recommend you read up on Views as there are numerous types. 

    I wasn't born stupid - I had to study.

Viewing 2 posts - 1 through 1 (of 1 total)

You must be logged in to reply to this topic. Login to reply