[throwawayboise]

I've been writing SQL for so long it's second nature. I have tried these GUI tools from time to time but for me, nothing beats just writing SQL in a text-mode window. I use emacs and whichever sql mode is appropriate for the database I'm working with.

If I don't understand the data model well enough to know how to write joins to get what I need, I have never found that a GUI helps me very much.

[eternityforest]

I think one big advantage of GUIs is safety. There's no shortage of people who accidentally typed a bad command in production.

GUIs usually don't let you operate on anything you can't see, so it's harder to do the wrong thing by selecting something without looking at it.

Like with dd, you can type /dev/sdWrongDrive and never see anything about the device. With a GUI you will click a button that says "Root Device: 67GB free of 128GB" and instantly see it is not your blank SD card.

[throwawayboise]

I have not seen a GUI tool of this sort that is substantially safer than a command line tool. If you're letting users do things like deleting or altering production data with any kind of ad-hoc tool, you've got a bigger issue than what the specific tool is.

[eternityforest]

Judging by meme threads, and comments on them, it seems like unfortunately nobody got the memo that it's a bad idea.

The usual issues are things like a select without a WHERE, least with a GUI, the tool can ideally do a select before any modifications happen, and say "You're about to affect 39482 rows out of 39482 total".

I suppose you could do things like parsing the SQL, figuring out the intent, and generating the select call, and throwing an error if it can't pre-check things on the CLI, but GUIs also have a speed bump effect that keeps the confident power user types from moving faster than their heads, and different expectations.

People seem to expect command line tools not to have layers and layers of confirmations and hoops to jump through, and the people who want this stuff probably prefer a GUI.