SPONSORS:






User Tag List

Thanks Thanks:  0
Likes Likes:  0
Dislikes Dislikes:  0
Results 1 to 5 of 5
  1. #1
    Senior Member
    Join Date
    Jun 2001
    Location
    Bend, Oregon
    Posts
    102
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    DB reorg: queries to be equivalent in new DB

    Hello,
    I'm testing a DB that is being reorganized into more table rather than a few 'jam-packed' tables.

    The only exit requirements from testing is that the queries used will produce equivalent results as when they were used on the older DB with it's table structure.

    I've been thinking about this for just 2 days now, but, it seems rather straight forward for testing the new DB!

    To test the queries, I think capturing the old DB results in a .CSV file, for the baseline. Next, capture the new DB query results in another .CSV file and then just diff them.

    Is this too obvious? There must be something further I can do to validate the newer DB as it is now populated. So, any comments regarding this are welcome.

    thanks,
    Bob
    Social Engineering - do they ever use QA?

  2. #2
    Senior Member
    Join Date
    Mar 2003
    Location
    Austin, TX, USA
    Posts
    1,489
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: DB reorg: queries to be equivalent in new DB

    .. Seems easy to me as well. Run a test on your old DB structure using enough data combinations to cover all cases and then run the same tests on your new database structure. If they come out the same, its a pass. Other things you may want to look into is some load testing. Using more tables may introduce some deadlock exceptions.

  3. #3
    Senior Member
    Join Date
    Feb 2003
    Location
    FL, USA
    Posts
    3,646
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    1 Thread(s)
    Total Downloaded
    0

    Re: DB reorg: queries to be equivalent in new DB

    I agree - I would look for same results in same or less time - if performance degrades then the changes to the DB are not optimum
    Lynne

    I have not failed. I've just found 10,000 ways that won't work" --Thomas Edison

  4. #4
    Advanced Member
    Join Date
    Aug 2001
    Location
    Minneapolis, MN
    Posts
    953
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: DB reorg: queries to be equivalent in new DB

    I don't know about all that. Database changes/migrations make me nervous. On the other hand, maybe I'm not reading enough into the original post.

    That having been said....

    I haven't seen anything about how data gets into the database, nor have I seen anything about what the data is used for once it gets there. These are more interesting to me. Not knowing anything about the queries and their purpose(s), it leaves things a little too vague for me.

    At a high level:
    1. Can the processes that 'generate' new data into the database continue to work successfully?
    2. Once there is data in the database, can it be modified/deleted after the changes have been implemented?
    3. Can new records be added to records that existed prior to the changes having been implemented?
    4. If there are processes that pull data from the database, will these continue to work successfully after the changes have been implemented?
    Jason Trebilcock

    "The single biggest problem in communication is the illusion that it has taken place."

    -George Bernard Shaw, Irish playwright and Nobel Prize winner, 1856-1950

  5. #5
    Senior Member
    Join Date
    Jan 2005
    Location
    Aurora, Ont., Canada
    Posts
    1,174
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: DB reorg: queries to be equivalent in new DB

    On face value the testing requirements are indeed deceptively simple, but you have to think about an "equivalent results" target. That may be fine for simple queries but, as Jason points out, that can play havoc with other applications that might depend on specific query responses. The obvious first step is indeed to extract query responses from both systems and to compare the results for differences, but that is only the beginning. You have merely confirmed that the data are not in any way corrupted by the transformation, and if that is the scope of your work then you are fine.

    Some databases have many applications dependent on specific structures, and it is important to do a regression test on all applications that now need to interact with the new database. You must not assume that the correctness of the data will demonstrate that the applications should not be affected. So I am in total agreement with Jason that there may be more to this question than what seems obvious on the surface.
    Frits Bos, PMP
    frits_bos@hotmail.com

 

 

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Search Engine Optimisation provided by DragonByte SEO v2.0.36 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Resources saved on this page: MySQL 9.09%
vBulletin Optimisation provided by vB Optimise v2.6.4 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
User Alert System provided by Advanced User Tagging v3.2.8 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
vBNominate (Lite) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Feedback Buttons provided by Advanced Post Thanks / Like (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Username Changing provided by Username Change (Free) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
BetaSoft Inc.
Digital Point modules: Sphinx-based search
All times are GMT -8. The time now is 10:04 PM.

Copyright BetaSoft Inc.