problem statement: Optimizing database query performance as also
                   underlying storage efficiency

Illustrative example: Refer to as described in 847) as the size of the data
                      grows in a table ..irrespective of the presence of the
                      of index's ....amount of time required or query performance
                      degrades ....reason being I/O of the underlying disk's
                      depending on nature and type of the database (properitery
                      those that use raw disk space) and those that use filesystem.


                   Ex: Take the case scenario of the Tax payers or filer's, supposed
                       that they are stored in a table TAXPAY ...as the years pass
                       by the amount of info stored in the table gets accrued,resulting
                       growth of the size  ...as ex

Opportunity :
-------------

 Ideally all objects with in a database are confined to a specific schema,
 and cannot extend beyond a tablespace or container.

 Given that objects can be relocated from a schema or tablespace ...
 a innovative way of purging the data is to , move non active or any data that
 is not current to a different tablespace.                

 Better way to handle the scenario to assume that data can extend beyond tablespace,

 a table can be split and located across tablespaces ...in the cataloges or reference
 tables setting a tablespace as active ...were in all queries are directed over active
 tablespace ....

Note: The above problem statement having been encountered in various scenarios
      and detailed in various 'Proof of concepts' as mentioned in 
      'http://uk.geocities.com/ravivenkatus/projects.pdf' ....apply appropriate
      'use-case' modeling, rationalize and arrive at a workable and feasible 
       solution both commercially and techinically viable.

option b
--------
 unix cut,paste, awk,sed utilities.


 given that most operating systems support virtual filesystems,

 in much the manner in which a filesystem reorganization or instance scandisk works,

 using a highly level query(at database level) ....identify the set of pages in the

 underlying disk that are effected  ....move these set of pages to different disk,

 given the manner in which virtual filesystems work ...re-draw or rely the filesystem

 map ....

 Given that some databases use raw disk space  and some use filesystems 

 ....embedded the above feature appropriately as part of the database or at the
     virtual filesystem management level ...given the complexity ...accomplishing
     it in a automated manner would be the ideal proposition (well data to be purged
     or relocated ...to be identified using a query though ...and using automated tools),

     thus keeping the tablespace virtually in tact ...and extents contigious  ...which

     requires minimal of modifications ...in database interface levels (SQL or schema or
 
     catalogues]