Ability to handle large number of database objects

Martin_PMartin_P Posts: 5
edited August 5, 2011 12:48PM in SQL Dependency Tracker
Hi, I'm running version and am trying to product a diagram from one of our data warehouses.

The warehouse contains approx 3500 tables and 3000 stored procedures.

I only want to produce a diagram for a small set of these tables.

What I find is when adding objects to the project that the selection of table names is very slow (via the UI) and that generating the model can take several hours !

I am running Win 7 on a well speced desktop.

I would really like to use this product for reporting and documentation, but the perform is hindering me at the moment


  • Options
    Unfortunately, given that you are attempting to feed over 6500 objects into the tool, I think that it is expected to take some time. Whether 'several hours' is right, I cannot be sure, but I wouldn't be surprised.

    The engine behind the tool need to read and parse the entire schema and calculate the dependencies which are then rendered to the UI as the resulting diagram.

    If you believe that there is an error or problem which is slowing down the process, then please get in touch directly at support@red-gate.com.
  • Options
    EdCardenEdCarden Posts: 136 Silver 1
    I face this same duration issue since our primary accounting database (used by our accounting software) consists of over 2000 tables alone (don’t ask how many other objects we have) . This problem could be easily over come for most scenarios by enabling some form of schema cache.


    1) Allow for storing the layout of an already queried DB Schema so that when the user goes to work on a project or start a new one they can opt to use a cached copy of the schema thereby greatly reducing the time to get the schema.
    2) Allow the user to restrict the schema query to specific objects types (i.e. all tables) and perhaps even to specific schemas (i.e. all dbo schema objects) so as to cut down on the number of objects the app has to load.

    The main goal should be to offer greater control of schema retrieval operations which currently is limited to selecting a specific DB on a server instance.

    Had I realized in advance it was going to take this long to start Dependency Tracker every time I used it I might not have purchased it.
Sign In or Register to comment.