Production Database Reducer Start Page English Hungarian

The software » Development - testing

 

 

 

 

 

The basic idea.
 

The database reduce algorythm was born becauseit is hard to solve the problem of the large databases by operating considerations.
The developed applications can evolve very complex relationships between data entities using the RDBMSes.
Thus, the database size reducing is not solvable only by dropping data partitions, because if there are dependencies, the database system correctly will not allow to drop it.
Or, if it allowes to drop table partitions or tablespaces (for example the application does not use foreign keys because of performantial considerations), then the application will not work correctly.
So, the problem seems to be not solvable by thinking as an operator.

But the developed database systems have statistics and metadata, which can be selectable by suitable privileges, this can be programmed.
In this way the original problem can be solved by think as a developer.

 

 

 

 

The development.
 

The development of the Production Database Reducer started by design of the key functions as any software development.
It was one of the most important things to create an algorythm independently from the databases, while consider the broadest subset of functionality of the most used database systems.

The first of the implementations was for the open source Postgresql.
This was followed by the Oracle, and then the Db2 and Mssql implementations.

 

 

 

 

The testing.
 

The developing of the testing codes started after the early final versions of all of the implementations.
The testing of the implementations of Production Database Reducer is fully automated. Testing of fixing a bug or developing a new feature is a very easy and quick process.
The tester codes are also a kind of software development, so these are also fully developed and tested, when it is needed to modify the tester codes after a new feature or bug fix.
We have the PrDaRe algorythm programmed on several platforms. If a UAT test case fails in only 1 implementation and passes in the others, this may indicate a software bug in that implementation. So, having these several implementations not just a functional but also a tester feature. It is very important to see how do the same functionality work in completely different database engines, exatclty the same test result is the expected.
In this way we can have the full software quality assurance.