Objects Tab And Large Databases

[tyrathect]

My company employs two databases, one for testing purposes, and another for the live data. While the test database has only few tables in it, the live one contains a real lot of them, about 4000. Now, it happens every now and then that I'm viewing objects of a table in the test database via the options tab; later, I need to do something in the live database, so I click the “+” in front of it to open the tree view for this database; now this is the moment I realize I'm still in the options tab while the live database becomes the selected object in the tree view, so the options tab now attempts to display all 4000 tables' properties at once. Naturally, this takes quite some time.

Now, while this can be avoided by paying attention to which tab you are in when changing databases, this is something you just don't think of most of the time before it's too late. So, I think it's worth considering keeping the current selection in the tree view when clicking the “+”, and just opening the tree instead, just like the windows explorer does (which is probably also the reason why one would expect SQLyog to behave in this way). Alternatively, automatically updating the options tab when selecting a database might be disabled, but I believe the first solution would be the more consistent and user friendly one.

[peterlaursen]

Thanks for your consideration.

I think the comparison with Windows Explorer does not quite 'hold water'. SQLyog is a database client and will need to communicate with the server whenever something happens at the client side. In this case we send a USE statement.

We will disucss this, but could you consider having two different connections with each of the databases specified for one connection?

[Manoj]

Hi,

There is an option in preferences that may be helpful. “Always select objects tab…” keep this option unchecked and make sure you are in some other tab while clicking the '+' in the object browser. Then it won't update the Objects tab.

[tyrathect]

Manoj wrote on Nov 22 2007, 03:49 PM:

There is an option in preferences that may be helpful. “Always select objects tab…” keep this option unchecked and make sure you are in some other tab while clicking the '+' in the object browser. Then it won't update the Objects tab.

Well, this is known to me already, as I stated at the beginning of the second paragraph of my post. The problem is always to remember to switch to another tab, it's just an issue of handling and comfort 😉

[tyrathect]

peterlaursen wrote on Nov 22 2007, 02:13 PM:

I think the comparison with Windows Explorer does not quite 'hold water'. SQLyog is a database client and will need to communicate with the server whenever something happens at the client side. In this case we send a USE statement.

Well, it was just an example to illustrate my point 😉

Anyway, what I'm wondering about is that it takes the objects tab exceptionally longer to display all the tables in a big database than it takes for the tree view. Since the tab always updates it's contents automatically, this is what makes it inconvenient in this case.

However, since there are workarounds, this is not really a problem but just an usability inconvenience which could maybe be addressed in a further release, maybe with an option in preferences to automatically switching to a specific tab when opening a database, or not to auto-update the objects tab in that case.

[peterlaursen]

Usability suggestions are always welcome!

I think in situations where:

* tables a not very big

* server is local

.. the current design is most intuitive. As per your proposal user would manually need to 'refresh' and I think it would be an annoyance!

However I realize that with big and remote tables it may not always be the case.

Should we include an uption 'not to auto-update data area' when 'something' is selected in Object Browser? (I am not sure how easy that would be however!)

[tyrathect]

peterlaursen wrote on Nov 23 2007, 10:42 AM:

.. the current design is most intuitive.

That is undisputed 🙂

peterlaursen wrote on Nov 23 2007, 10:42 AM:

As per your proposal user would manually need to 'refresh' and I think it would be an annoyance!

This is true, too, and a much greater one than waiting for the objects tab contents to update on a big remote database 😉 That is why, if ever this gets implemented, users should be able to turn auto-updating on and off, and secondly, this setting should not apply unconditionally to just any object but users should be able to make different settings based on the object type, as you already suggested in your post.

[ChrisB]

Perhaps a new checkbox preference could be added for each connection record: “Slow/remote connection: object/tables tab should not auto-refresh”.

A system-wide preference about whether that checkbox is auto-selected by default for new connections could also be added.

Then, whatever that setting is would determine the refresh behavior of both the “table data” and “object info” tabs. If the “slow connection” option is checked, then perhaps instead of auto-refreshing the content in the “object info” and “table data” tabs, a refresh button could appear … thus giving control to the user.

Alternatively, when connecting to a given database, one could do an nslookup on the server address (or tunneling URL as the case may be), convert it to an IP address if necessary, and check to see whether its address is “local” to the subnet of the computer running SQLyog. And, if it's found to be “local” it could be treated as “fast”, and if it's not local to the subnet, treat it as “slow”. In this case, the per-connection-preference could be overridden by the discovered speed.

(I don't have any problem with the “object info” tab being refreshed. I often find unexpected delays for table data when clicking on different tables in the table list. Fortunately, unchecking the “show all” box, and using a smaller number in the limit boxes is helpful. This is the reason why I included the “table data” tab in my comments above.)

I wouldn't consider this to be a huge or serious issue … but something of a possible enhancement down the road. As the original poster has noted, there *are* workarounds.

[Author]

Posts