CODEWITHSUNDEEP
sql-serversql-server-2005sql-server-2008ssms
MrEdmundo
MrEdmundo

Reputation: 5165

SQL Server Object Organisation

I'm not sure if this is valid, however I have a bug bear with SQL Server, and that is that I cannot organise objects in to a group of objects.

Imagine I'm working on a new section of work in a large database and I perhaps have 15 objects that I will be regularly using. What I want to do is sort of "Favourite" them in to a folder so that I don't have to trawl through all objects in my databases.

I know I could organise objects by schema, however these objects aren't necessarily schema specific, they cross boundaries.

Has anyone come across a method for organising objects in to a favourites group? I know SQL Server Projects organise scripts, but I can't see that they can organises tables?

Thanks

Upvotes: 1

Views: 254

Answers (2)

Aaron Bertrand
Aaron Bertrand

Reputation: 280615

I know I'm really late to the party, but the question showed up on the right under "Related" and I was curious enough to look.

There is a free add-in for Management Studio that seems to do exactly what you're asking:

http://www.sqltreeo.com/wp/dowload-free-ssms-add-in-to-create-own-folder-for-database-objects/

There is also a $65 commercial add-in which you may want to try as well. I haven't tried either so I'm not sure how well they work or what the paid version offers over the free add-in (if anything).

http://www.skilledsoftware.com/

Also can't hurt to vote for this Connect item and add a comment describing your business use case. While you may find it discouraging that it's been closed as Won't Fix, that is not necessarily a permanent decision:

http://connect.microsoft.com/SQLServer/feedback/details/209340

Upvotes: 0

Brent Ozar
Brent Ozar

Reputation: 13284

You can't do that with the native tools (SQL Server Management Studio) but there's a workaround: create a new empty database with those 15 tables - just the schema, not the data. Then when you're writing T-SQL code, you can quickly drag and drop elements out of those tables into your code.

The downside is that changes made in the real database won't be reflected in your working database, but you can automate that with a script to pull out the objects you need and recreate them in your working database. You can run that as often as you like (like every X hours, or as a SQL Agent job that runs when your local dev server starts up) without losing data, since you won't be modifying the structure in your "favorites" database.

Upvotes: 3

Related Questions