Thanks for the pointer, I hadn't looked at it and so was keen to see what it was about. I like it, as far as it goes, but here's the thing: getting a list of database objects (eg tables) is trivial, and getting a list of table constraints (including relationships) is only slightly more difficult. The hard part is to obtain useful information about those relationships, and that's where MSSQL::TableReferences comes in. It is about discovering and interpreting information that is buried in the database schema.
Perhaps it is peculiar to my style of orientation, but when I'm studying a legacy database, I first review any ER diagrams, and then I look at the declared relationships. I find that these relationships are usually far more enlightening than anything else, since they are about as close to the big picture, fundamental design decisions, as anything can be. I can do this manually of course, and I do, but with this package I can speedily collect and publish the information for further reference. I'm essentially inventing yet another reverse-engineering tool, born of my working practices.
I notice that SQL::Translator::Schema provides for what it calls a natural join, which turns out to be a naive assumption based on column names. This might be helpful, but it is far less helpful than the examination of declared relationships from sysreferences.
Still, it has given me more to think about. Thanks again.
| [reply] [d/l] |