distal-attribute
distal-attribute
distal-attribute
distal-attribute

Improvement suggestions for HeidiSQL inspired by phpmyadmin

User, date Message
Written by lemon_juice
4 years ago
Category: Feature discussion
127 posts since Tue, 29 Jun 10
I've been using HeidiSQL for about 2 months, previously I used mostly phpmyadmin and sometimes the free sqlyog for data exporting/importing. I find Heidi to be the most convenient overall but still from time to time I switch to phpmyadmin for certain tasks. I think it would be great to be able to stop using PMA completely since it is pretty slow. Below I will list the features I like in PMA but are missing in Heidi:

1. Search form.

This is more or less equivalent to Heidi's filter but what is really nice in PMA is the form with all table fields where you can enter what to search for and specify the operand for each field. You can also choose a field to order by below. This is very convenient because you don't have to manually type the where clause when you want to do a simple search. And this is what I do most often - I want to find a row with a specific ID or find rows matching a text column with LIKE - then I just click search, enter an ID or string in the appropriate field, click Go and it's all much faster than having to type something like 'subscription_id=450' in the filter box. I haven't found anything like this in Heidi but I think it would help a lot in being more efficient. I would imagine this to be integrated with the existing filter somehow. Also, right clicking on a table field (both in the table and data view) could have an item 'Filter by this column', which would take you right to the search field form with the cursor active in the chosen field. That would be really a killer feature!


2. Multiple tabs.

This is not a feature of PMA in itself but in practice we can assume it is because it is provided by browsers. You can open as many tabs as you wish with different views like table schema, data, filter (search) results, other query results, etc. I know Heidi has tabs but they have their limits, for example you cannot have multiple tabs for data or filter for the same table, or multiple tabs each with query results from different tables or databases (unless you type your multiple queries into the query tabs) or multiple tabs each with structure of a diffent table. What I would imagine for Heidi is the global tabs on the very top of the application (probably just above the top toolbar) and each tab would contain a sort of separate instance of Heidi - just like I can do it now with opening multiple windows of Heidi (but probably there wouldn't be a need to make separate connections to the same server for each tab). Then there could be some convenience right-click menu items in the tree panel like 'edit this table in new tab' or 'view data for this table in new tab' or 'edit this database in new tab'.


3. Browse distinct values.

Sometimes I find this a very convenient one-click feature in PMA. This could be a right-click menu item in the table view tab and would automatically create and execute a query like this:

SELECT COUNT(*) AS `Rows`, `field` FROM `table` GROUP BY `field` ORDER BY `field`;


There are also some other minor improvements I would enjoy in heidi but to me these are the most important ones which would contribute to much quicker workflow. Please consider them if you find them worthwhile and possible to implement. Heidi is already very good, thanks!
Written by ansgar
4 years ago
4988 posts since Fri, 07 Apr 06
1. Did you try Search > "Find text on server" ? Sounds similar to what you are looking for.

2. That is issue #1663

3. Distinct values are there when you right click into the data grid ("Data" tab) > "Quick filter" > "More values" > ...
Written by lemon_juice
4 years ago
127 posts since Tue, 29 Jun 10
1. Yes, I tried it, it's somewhat similar but not there yet. Personally, I think in most cases it's superfluous to search for text in all possible fields. When I want to find something then in 99% of cases I know which column to search and searching in all others can only create unnecessary confusion. I understand that feature may have its use but I think the search form in PMA is much more handy. There's also a problem with large tables - when you try to "find text on server" in a large table then you almost always end up with full table scan, which can take really long, while searching by one column only can use an index if it's there. If I were to choose, I would definitely prefer the PMA-style form. Here the search feature could have an advanced version with a separate search field for each column.

2. Thanks, I didn't know. This doesn't sound promising as it is complicated to implement as you say.

3. Well, that's close but for any larger amount of distinct values that is not very useful. I can use a workaround by navigating to "More values" and then copying the query from the query log, not very convenient but at least possible. It looks like this would be the easiest to implement because it's already there, it would only be a matter of adding a context menu item "Browse distinct values" which would do the same as "More values" except that the query would be automatically executed in a new query tab. What do you think?
Written by ansgar
4 years ago
4988 posts since Fri, 07 Apr 06
1. For more specific find operations the data grid has conveniant filter features. Or use the "Find text" dialog. I won't add some third dialog for some "inbetween" logic.

2. We'll see - I already did a lot where I first saight that's complicated

3. Didn't knew you want distinct values in a query grid. You can a) use "Copy line to new query tab" from the log, or b) write a query and save it as snippet you can access via right query helpers.

In fact you will always find features in other clients which are not or differently implenented in HeidiSQL. I'm not going to accept arguments like "this is something I am used to in PMA". HeidiSQL always has its very own way for getting everyday tasks done.
Written by lemon_juice
4 years ago
127 posts since Tue, 29 Jun 10
1. Okay, partly I stand corrected because I didn't know that the quick filter col='...', etc. means that Heidi will ask to enter my own value to search - that takes care of quick searching by a single column. But still there are cases where I want to use a quick filter to search by multiple columns, I don't see such a feature in Heidi. It's not a question of me being used to PMA but being able to accomplish a given task efficiently, I don't mind if it's done differently than in PMA, PMA is just an example. So the task is - I want to do a quick search by 3 columns, for example:

SELECT * FROM table WHERE col1>=2 AND col2 LIKE 'pre%' AND col3 IS NOT NULL;

How do I accomplish this task in Heidi without manually typing the where clause? In PMA I simply enter the values in appropriate search fields and press Go. It would be great if Heidi could do the same - it's not a problem for me if I would have to do it differently, the important thing is that I could do it equally efficiently.

2. OK!

3. Yes, I have found these solutions, I was thinking more of a one-click solution - I agree this is not a really important feature so I don't mind, it just seems easy to implement, I think.
Written by ansgar
4 years ago
4988 posts since Fri, 07 Apr 06
Ok, then issue #1085 is the one you are looking for - the whole filter controls could get some refactoring, which includes defining filters on multiple columns.

Btw, did you see the "Table wide filter" in the upper right of the "Data" tab?
Written by lemon_juice
4 years ago
127 posts since Tue, 29 Jun 10
Ok, then I'll add some comments to issue #1085 regarding filters.

What do you mean by the "Table wide filter"? I can only see a "multi column filter" - is that what you mean?
Written by ansgar
4 years ago
4988 posts since Fri, 07 Apr 06
Ah yes that's what I meant - that label was renamed recently.
Written by lemon_juice
4 years ago
127 posts since Tue, 29 Jun 10
Yes, I have tried the multi column filter, I use it occasionally but personally I'm not very fond of it because it can create long and hard to edit queries and it results in full table scan so it's slow for large tables.

I have added comments to issue #1085 and issue #1663.
 

Please login to leave a reply, or register at first.