SQL Clone
SQLServerCentral is supported by Redgate
Log in  ::  Register  ::  Not logged in

SQL Treeo – Extended properties or local file – please vote


I was trying to solve SQL Treeo’s performance issue on slow connection. This posts is also covers feature request of having separate folder structures for each developer (store folder structure in local file). SQL Treeo currently stores object’s folder name to its extended property named “VirtualFolder”. This helps to identify which object belongs to which folder.

Advantages of this apporach:

- folder integration is completely seamless as it’s part of database data (extended properties of e.g. stored procedure)
- if it’s shared database, other developers with SQL Treeo installed have access to same folder structure


- it’s slower on non-local connections. It’s because of fetching extended properties using fn_listextendedproperty one-by-one. For database with thousands of objects accessed via e.g. VPN, it’s slow. (fetch all extended properties in batch is possible but not usable within add-in).
- it’s limit for storing more attributes to folders (such as color, completely own structure etc.)

Based on that, I would suggest to completely get rid of storing folder name to extended properties and store them to local file instead.


- performance, no access to database is needed (probably only EXISTS for objects within folders)
- each user could have its own folder structure
- more flexibility for future enhancements (such as mixing more SQL object types in one folder.)


- local file will not be shared with other database developers by default. However this could be solved by storing this file to any source control or placing it to network shared folder.

Please let me know if you agree with new “local file” approach.

Use this poll:

Note: There is a poll embedded within this post, please visit the site to participate in this post’s poll.


Tags: , , , , , , , , , , , ,


Leave a comment on the original post [www.sqltreeo.com, opens in a new window]

Loading comments...