For example, if you only enable root@localhost to have GRANT OPTION (or replace with the administrative permission of your choice), it's not always easy or convenient to do port tunneling so you can use a GUI. OTH, the MySQL CLI utility will always be there on the server.

My $.02
G

There is value in exposing a little bit of MySQL at a time.

I use a separate editor for when I'm creating stored procedures or events, long pieces of code that I likely will troubleshoot for a while before getting it right.

I understand that someone used to a GUI may look at that as an abomination, but for me this is one of the simplest uses of the MySQL CLI integrated to shell tools. There are more complex, and more powerful things that can be done, and I feel very much satisfied with the command line for this reason. I would be lost in a GUI, which is in many cases very limiting for me.

When is a GUI helpful? When you have to create queries from a complex schema and you need an enhanced editor that suggests you table and column names efficiently. I use Aqua Data Studio for this reason only.

And your tool wants to be smart. Who wants to use a stupid GUI tool? Being smart is important.

Everything that is smart falls into the corner of not satisfying the minority who actually want something else.

I'm suggesting that the command line client, being not-smart, shows the de-facto real picture, and is the place to go to for reference.

I can understand your concern about using Command Line and other Visual Editors.
Using any Visual Editors definitely you will not be known to syntax for DDL and DML statements.
For student or MySQL trainee one must use command line for basic SQL operations and understanding MYSQL internals i.e. Related to server metadata, user management etc..
Once they gain intermediate knowledge about SQL and MySQL internals.. they can opt for Visual tools using this they will improve productivity and something which is found in Visual tool not in command line (Like LIMIT 1000 and pagination kind of result set) as they already gained enough knowledge to check what queries being executed in background.
Also using Visual tools they can save time for doing tasks such as CREATE TABLE, FK RELATIONSHIP , Build queries, Optimize queries, User Management, Sync Schemas/Data etc.. which can be difficult and time consuming tasks using Command line isn't it?

There are reasons why GUI tools behave in certain ways. A lot of thought has been put into each of these aspects.

For example, I want to explain why there is a limit of 1000 rows in SQLyog "by default", as this behavior has been specifically pointed out in your post.

In the command line, it takes a little more effort to look at the contents of a table. At the very minimum, you have to type "select * from ".

In SQLyog, viewing the data is just a single click on the table name. When it is that simple, users have the tendency to click on one table after another in quick succession when they want to "study" a database. They just want to quickly look at a few rows and see what type of data each of these tables contain.

For such use-cases, it would be annoying to bring up all rows of a table if that particular table has thousands of rows. It is just wasteful -- both on the client and the server.

Earlier versions of SQLyog didn't have this "feature" We built this based on feedback from thousands of SQLyog users.

Like I said, most students revert back to whatever feels more comfortable to them, and I don't object.

If my post read to you like "I do not allow use of GUI tools in my classes", then I have failed to deliver the message properly. It is not as such, but rather "I see importance that students know how to use the command line and that what they get from visual editors may not be consistent with what they get from command line". And I confess I do encourage them to use the command line, after all.

To the other extreme, I don't think the learning process should fully comply with whatever students are doing and using. For example, if they all use Windows, that doesn't mean I shouldn't be telling them on the advantages of using MySQL on linux. I may just even go as far as suggesting that they should try linux.

I think you have also extra-extrapolated your conclusion about "the dogmatic one true way". I did *not* say people should not be using visual editors. I *do* say they should be using the command line. To be very verbose: they can do so even while working with their visual editors. I stand by my point: if you don't know how to do it with command line, you can't really know how it's done.

"I don't know it. It sucks" is truly a bad approach. I do not think I take this approach. Since you do believe I do, allow me to take a few days to reflect upon myself. It is possible others see in me things I do not see in myself (though a bit extreme to diagnose a person from a single blog post), and I will think this over as good measure.