Does this utility go down to the field level for dependencies as well?
Comments
22 comments
-
Hi jvance,
We do track dependencies down to the field level, but we don't display them as such; on the diagram and in the Object Dependencies list, the dependencies will go to/from the table in question.
All the best,
Dan -
Hey Dan,
Thanks for the reply. Could you give a brief overview of let's say, I am trying to find where a field is used at in all of my db's. -
Agreed.
One of the main reasons I'd purchase such a tool is that I'd like to be able to track what would be affected by a column drop, name change, split, etc...
Also, differenciating (maybe as simple as color-coding) between a column being involved in a SELECT clause versus a column in a JOIN would be even better.
- alphadog -
Hi all,
Since we track at the table level, one way in the final release will be to drop the table whose field/column is of interest onto the graph (which will bring in all objects which that table is used by). We're aiming to show source SQL for the dependency objects, which should allow you to determine which references apply to the table and which to particular columns.
We're still considering colour coding dependency types, although given the large number of ways in which references can occur, we figured that showing the source SQL would let the user get right to the meat of the problem more easily. Do let us know what you think though.
Hoping that's of help,
Regards,
Dan. -
There is a problem with looking at the table-level to understand column dependencies. For example, assume I have TableA, used in three views A, B and C. In TableA, we have columnA, used in two of the three views, say A & B. I will see and have to look into view C needlessly to see that while TableA is involved, columnA is not.
Sound simple, right? Exapnd the problem to a serious business database with hundreds of tables, and you could end up looking at a lot of dependencies needlesly when trying to get the ramifications of, for example, a split of an important column.
I guess what you are saying is that, currently as designed, RGDT is unaware of columns as objects? It won't stop me from buying this product, but table-level views for column dependencies just won't cut it. I hope it makes it into some near-term version...
- alphadog -
Hi all.
As probably mentioned by many others, the core of this (great) tool success will be the capability of classifying all dependencies (column included) for later analisys.
The graphic part is nice, but not for DBs with a lot of objects.
The XML output is great; an interface to most common RDBMS will be even better, especially if the entire process (select, parse, save to table) can be made automatic via command line mode !
When the next release? (beta or final)
-LF -
Agreed.
The real gold in this software is the data. I don't know if RG thinks that the visuals are the meat, but just in case, I'll re-iterate that the visuals are the sizzle, but the steak is the data. The sizzle doesn't last; it's a good steak that keeps you coming back to the restaurant.
I would caution that if RG's backlog of tasks on this software isn't at least partly focused on expanding and exposing the data, RG may be heading in the wrong direction with the product since developers will appreciate the graphs but will love many of the more silent things (query interface to data, expanded depth of dependency checking, command-line control and export, linking into other development tools, etc...) being mentioned in this forum. I don't mean this as negative criticism, since it is alreayd a great product; I'm just trying to think "what do I expect next?".
- alphadog -
Absolutely!
While I always appreciate a good user interface (btw not sure about the menu panels?), and did go WOW when the diagram morphed from one configuration to another, that won't convince me that I need this product.
Features should be:-
reliable dependency data
a simple user interface to drill down the dependencies
a simple HTML/XML reporting option (like SQL Compare)
and automation.
To reiterate AlphaDog's sentiments, this isn't meant as negative criticism. I'm trying to highlight the need for development tools like SQL Compare. A successful tool for the busy DBA.
If this product is marketed towards Pointy Haired Boss
then concentrate on the diagram feature. If its the DBA or DBD then we need need Automation and solid dependency data.
"Steak" over "sizzle" every time!
Alex Weatherall
TeleWare.com -
I know that graphic of the entire diagram with the "moving" effect is a nice selling point (to management :shock:), but I would provide the possibility to make the full diagram completely optional (ok, make it on by default
) ;
Graphically wise, I wonder how useful and productive could be to have a graphical representation limited to dependecies (both directions) of object(s) selected in the "Objects Diagram" or "Objects Dependencies" panels.
Same output (combination of Graphic and/or text) would be great as report too.
LF -
Hi everyone (sorry, it's getting late on a Friday to still be here),
I think those are some great ideas. I can particularly see where you're coming from with the automation. All I can say really is watch this space. We've still got quite a chunk of work to do before the final release, which should be within the next month or so, so obviously the number of additional features in the product won't be great. What we want to concentrate on is making it solid, and ironing out the glitches and bugs.
Adding field level support is certainly an excellent idea, and one I can see us pursuing in the future, however unfortunately I can say that for this release it won't be going in simply because we don't have time to make a proper job of it. However, as I say, I can see us perhaps adding that functionality in the future.
What may help in this respect, although from what Alex has said above, it's a far from perfect solution, is displaying the source SQL within the application. This *is* something we're planning to do for the final release, although at this point it's not absolutely definitely going to be in there. As I've said in another post, that's kind of a weaselly comment on my part, and I apologise for it, but at this point I'm afraid I can't be more specific.
Anyway, hope that helps. As I said, watch this space, because there are a lot of great suggestions there, and I'd certainly love to be able to say yes to all of them. If you've got any more ideas we'd be more than glad to hear them. It sounds like a bit of a cliche, but the customer feedback we receive ultimately does define the new versions of products we create, so we're really grateful for anything you have to say (good or bad) that would help us make improvements.
Many thanks, -
Hi Bart,
a great help for "us" and for "you" would be to have access to a list of bugs currently found and a list of requested features.
This would help us in time saved to report something already known (in both cases).
For the wish list, a voting mechanism could help you to determine what can be the most popular request.
Your products are very well known in the DBA arena to be easy and of great use; a "wish collector" mechanism should help you in keeping all of us on the lookout for the following release.
Have a great weekend
LF -
Hi lfagetti,
Thanks for that: I'll certainly suggest it. We do find it can sometimes be problematic getting feedback from users when we need it (who in the software development field doesn't), so we're always trying to find ways to make it easier for people to give us their ideas or suggestions. Something like this may well be helpful in doing this.
Thanks, -
Hi all,
This is a very interesting thread to read, and I'm still mulling it over. Hence my late reply to this thread; apologies for that.
A key use case we are aiming to support with SQL Dependency Tracker is impact analysis. For example, say as a developer/DBA you've got to change X, Y and Z tables. You want to know what other objects are going to be affected by this.
Now the way to do this as we designed it in Dependency Tracker is to go to Add Objects to Project, pick just the objects you intend to change (so in this example tables X, Y and Z), and hit "Add to Project". Dependency Tracker will add all those to a diagram, but will also automatically add all objects which tables X, Y and Z are used by; and all the objects those are used by; and so on. So your initial diagram should answer that high level question pretty immediately.
Where the objects that have been added have dependencies which aren't on the diagram, there'll be little stalks (a la "O----", if I may use brief ASCII art) sticking out of the objects on the diagram. You can mouse over those objects for a list of dependencies which aren't shown, and then right click to add those objects to the diagram.
So the drilling down process would start with a few objects on the diagram, and more are added as you drill down to what you're interested in. We were anticipating that people would use the tool in an incremental way, adding objects to the diagram as needed.
Interestingly it seems a lot of people are using the beta by adding everything to the diagram and then going from there. Now if your database is complex this is going to give you a bit of a headache, as you're trying to visualise the whole thing at once, and you've got many, many inter-depencies. If the original task was impact analysis, that's a lot to navigate, as people have discovered.
So a few questions:
Is change impact analysis one of the main reasons you'd use dependency viewer? If not, what's the biggest reason you'd use it?
Could you (would you want to) work in the way we invisaged for this task, or do you think we're off base on this one?
Thanks for your feedback, and all the best,
Dan
Dan J Archer
SQL Dependency Tracker Project Lead
Red Gate Software -
Hi Dan,
I think that your vision of a typical usage pattern is not wrong and it address the need of many;
However, in the case of large shops (usually as messy as large), there is the need to have an handy and complete picture of dependencies to be used for:
Auditing
Navigation & Prevention & Planning
I would envision the use of this tool as:
Daily collection against a set of DBs
Conversion to a friendly relational structure
Comparison with previous data to detect changes
Usage of latest collection to support:
Analysis and planning
Code review
Emergency lookups
ERD tools are getting closer to provide similar capabilities, but with a much higher cost.
SQL Compare is offered in two flavors; DT could be offered in the same way:
Simple (Interactive only)
Pro (Simple + command line, ...)
I'm pretty sure you'll be able to say:
"It's used by over 150,000 DBAs, developers and testers worldwide because it's easy to use, it's fast and it saves time. " for DT too!
LF -
Dan:
I would use RGDT mainly for:
- imapct analysis
- change auditing (although, darn, it won't tell you who did the change so you can hunt them down in cold blood!)
- sourcing data/images for adding to automated development docs
I think the reason most beta testers dump a whole db into your app is a function of:
a) Lack of initial guidance in the beta process. You might consider some sort of in-app introductory page for first-time users.
b) UI design for staring a project plus typical user laziness. People will likelier just "dump all" then find what they need, rather than pick out first. I know I did. If the UI instead asked for a single starter object, it might be a different outcome in user experience.
- alphadog -
YesDan J Archer wrote:Is change impact analysis one of the main reasons you'd use dependency viewer?
Yes. I never considered trying to work that way. Perhaps some "Best Practices" documentation or tutorials would be beneficial to new users (like me!).Dan J Archer wrote:Could you (would you want to) work in the way we invisaged for this task, or do you think we're off base on this one? -
Hi,
I would use RGDT for:
:arrow: impact analysis. After your description of how you had expected users to use DT I can see it's uses here. However...-
Alphadog's comment is pertinent. The initial user interface allows you to add all database objects too easily, giving you the impression that you can or should use the tool like this.
I think the initial user interface is complicated by the list of servers. This could be be a far simpler affair: connect to the database ala SQL Compare. Then why not have the "objects in database" panel (and search engine) as a dockable window instead of in the initial wizard. The search engine is great. Good that it narrows down the list.
Having used the product a little bit more in the manner you expected (i.e. adding specific objects to the project to examine their dependencies rather than "diagramming" a database) I see the benefits a bit more than I could. However I found myself just using the "objects on diagram" and "object dependencies" panels (I dock one to the left and one to the right and fill the screen with them to get rid of the diagram) to navigate round. I find that the diagram isn't an efficient way to navigate round the dependencies. If you have an object with many dependencies, you have to zoom in and out to follow the dependency lines and when zoomed out, you can't read the object text. I find the "objects on diagram" panel far easier to use than the diagram itself.
Alphadog also said he would use this tool for change auditing. Surely you'd use SQL Compare for that. I don't understand how RGDT helps in that respect. Alphadog, can you explain how you would use this DT to audit changes :?:
Thanks
Alex Weatherall
TeleWare.com -
Alex:
You'll have to forgive me as I have not used SQL Compare. I use a different product that is similar from another vendor. I'll assume it generally does the same thing, which is to find textual differences between DDL statements for same-name objects.
SQL Comapre and RGDT are complimentary, but not exactly similar, in the data they collect. However, sematically, the data is very different. In the former, it's raw textual diffs catching more variety of changes, in the latter you get explicitly-stated relationships between objects, but only that. The former may catch differences in the FROM statement, the latter will directly tell you that a view that used to include tableA does not do so anymore.
So, if I drop a table in a view in a database used by four business-line apps, it's (theoretically) easier for me to determine that appB will fail by rummaging through explicit relationship data (especially automatically) rather than "semi-structured" textual diffs.
My "wet dream app" would be to marry the dependency checking in RGDT (sans visuals; command-line outputs) to track all the way into .NET source code and make it part of an automated build/test process here at work.
Does that make sense? I may not have explained it correctly. -
Alphadog,
I see what you're saying, so the change audit in this case would be comparing, say, the XML output of RGDT for version 1.1 of your database to the XML output for version 1.2. This would give you the high level changes on dependency and so help with troubleshooting etc.
I would also use the RGDT output in database documentation generation. I'm working on an autogenerated documentation process, and it uses sysdepends info to provide links to related objects in the documentation. It would be better to use the RGDT XML output as it is more accurate, but this is a side benefit.
Yes you're right, we need something like the build and Source Control logic of DBGhost, the Dependency data from RGDT and so-on all building into one process. We have a in house process here, that is partly automated (getting better), and so it's just a case of plugging in the RGDT information at the appropriate points. We all seem to roll our own database build processes, it would be great if there was the product out there to do it all for us! But I guess that would spoil our fun ;-)
Alex -
Chaps,
There's some great feedback here, and many thanks for it. We're still digesting it all, and as you've no doubt surmised a lot of this is beyond the scope of our 2.0 release. That said, there's some very good food for thought here and we're most grateful for it. Your words are not falling on deaf ears.
Cheers,
Dan
Dan J Archer
SQL Dependency Tracker Project Lead -
To Dan's comments back on the 5th....
To the issue of your use case. It's use case scenarios that are very helpful for a successful beta experience. If you were to have released a readme with the beta explaining this, and possibly other use cases invisioned by red-gate, you would have really imporved the initial experience and feed back from your testers! Got any more visions to share with us?
One annoyance I've found is the apparent lack of ability to REMOVE something you've added. Yes there's a "remove from project", but if you add an object X that itself uses 100 objects, there seems to be no easy way of undoing that action. you can remove object X, but the 100 other objects are now mixed in and not easy to "undo" -
Thanks Dwaine,
A good point duly noted.
Cheers,
Dan
====================
Dan J Archer
SQL Dependency Tracker Project Lead
Red Gate Software
Add comment
Please sign in to leave a comment.