Centralized Data schema for all gathered information’s:

What does a centralized data schema means in this context? For the data collector there 2 existing ways to store the extracted data from the different data sources (tool types).  One is to store the data in one global database schema, with tables for every tool type, for example a table for the transformed SVN data from the SVN gatherer.

Advantages:

It is simple to administrate.

Not a lot of server performance used compared with the decentralized version.

Disadvantages:

Can form a bottleneck if too many operations are executed on the schema.

Decentralized Data schema for all gathered information’s:

Advantages:

Separation of concerns, every type has its own schema.

Better backup strategies possible, per schema for example.

Better extensibility, for example if more load occurs as expected the schemas could easily moved to an extra database server.

Disadvantages:

Small overhead for the Database system.

Small overhead for the database administrator.

Conclusion:

To store the collected raw data in databases per system brings an extra boost in performance and parallel working abilities. But more it brings extra advantages in the administration and security side. It extends the possibility to move the schemas on different servers, if the load is more than expected, or even if one server moves to another. Further it brings separation of concern in the database schemas, so the backups could be planned per tool type and its database. A downside is it asks more administration needs then the one schema solution.

Decision:

The decision is to use a database schema for every tool type. This decision is based on the conclusion above. The database schema per tool type brings the needed extensibility also on the administration side. It also brings flexibility in moving the schemas or even to delete them when no data Gatherer for this type exists.