(1): That of course varies greatly depending on your usage. One thing
you will probably want to do is to keep a weekly/monthly chart of the
size of your database, so you can use that data to extrapolate future
growth.

(2) One mostly queries for SCM objects in the context of a specified
stream or workspace, which keeps the size more manageable. I do believe
that we will need better baseline namespace management (some work items
have been posted for that). In general, if you see a particular area
where size of items is a concern, please start a forum thread or post a
work item. Many objects are grouped by project/team area, which gives
you control on scoping.

(3) Current support for archiving is primarily for UI complexity
management, i.e. the objects still exist in the repository, but are
hidden in the UI. For actually removing data from the respository, last
release, we added support for work item deletion, and we're working on
versioned item deletion for the next release. But note that this is
actual deletion ... the deleted objects cannot be restored.

Cheers,
Geoff

On 10/28/2011 11:38 AM, xophe wrote:

I was recently asked:
Scenario: 5 years of 100 users actively working with RTC (and RQM),
hundreds of java projects, components, thousands of baselines,
snapshots, change sets, work items etc --
What about Storage of data in the db: after a certain
time there will be millions of items in the db (too much data)
How to clean this? What is stored in the database (only indices or
also content)? How to keep it simple? How to manage this information
overflow (baselines, snapshots etc)? e.g. history of thousands of
changes on file? Possibility to archive?

I see 3 main questions:
1) Structure and Growth of the DB size?
2) How to handle 'historical complexity' of growing number of
baselines, snapshots, change sets etc after years of development and
10000's of changes ?
3) Is there some RTC Archiving possibility of e.g. Component or (old)
File change history ?

Any benchmark figure, info, hint, tip, work item, article on above (on
top of https://jazz.net/library/article/641) welcome!

Thanks