search

prabowomurti / sequel-pro

Automatically exported from code.google.com/p/sequel-pro
Other
0 stars 0 forks source link

[REQ] Usability: in the list of indexes, change "non_unique" column to be "unique" - easier to understand at a glance #774

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
I'm usually interested in quickly answering the question "is this a unique 
index?" - switching to the Structure | Indexes view for a table, you quickly 
see the answer to "is this a not unique index". 

Inverting the shown information should be a small change, and it would 
certainly make my brain happier.

Original issue reported on code.google.com by laust.rud on 30 Jul 2010 at 9:21

GoogleCodeExporter commented 9 years ago 
I agree with this.

MySQL uses "non-unique", and i also find it a bit confusing.  Since SequelPro 
is meant to simplify interaction with MySQL, rather than simply clone it, I'd 
really like to see this implemented, so I can quit saying "My column is not 
non-unique".

Original comment by mainstre...@gmail.com on 30 Jul 2010 at 10:43

GoogleCodeExporter commented 9 years ago 
Agree - in fact, I think the whole Indexes view needs streamlining!  One line 
per index getting rid of some of the extra info would be cleaner...

Original comment by rowanb@gmail.com on 30 Jul 2010 at 11:02

GoogleCodeExporter commented 9 years ago

Original comment by stuart02 on 8 Aug 2010 at 12:19

GoogleCodeExporter commented 9 years ago

Original comment by abhibeck...@gmail.com on 24 Mar 2012 at 1:09

GoogleCodeExporter commented 9 years ago 
Agree - I suggest the following layout to display what's currently shown in the 
attached screenshot, as multi-column indexes are always tricky to decipher with 
the seq_in_index implementation as well

INDEXES
=======
Name         Unique?    Columns           Cardinality*     Collation*†   
Sub_part*†     Packed*†     Comment
PRIMARY      [X]        id                267227           A             NULL   
        NULL
account_id   [X]        account_id, key   267227, 267227   A             NULL   
        NULL
key          [ ]        key, value        18, 267227       A             NULL   
        NULL

* Tooltip explaining the meaning of the column
† Remove column or only show in a "details" view

Even more awesome: clicking an index could highlight the indexed columns in the 
structure view. Some other indication of primary-indexed columns in the same 
structure view would also be nice :)

Original comment by firehed on 19 Jun 2012 at 11:14

Attachments:

GoogleCodeExporter commented 9 years ago 
I had a chance to go to WWDC this year, and took the opportunity to take Sequel 
Pro to the design labs.  He actually recommended breaking up the structure view 
into two tabs - one for the columns, one for the indexes, for a cleaner UI.

I agree that it'd give a cleaner UI, and so give more space to expand details 
across multiple rows even; but I'm concerned about losing the at-a-glance view. 
 If people were to gain *some* cleaner index indications per-column, what do 
you think about a move of the indexes view?

Original comment by rowanb@gmail.com on 20 Jun 2012 at 12:37

GoogleCodeExporter commented 9 years ago 
(And yes, firehed's suggestions look great and tally with my thinking.  
Multi-column indexes could also be a disclosure tree, expandable for full 
details.)

Original comment by rowanb@gmail.com on 20 Jun 2012 at 12:38

GoogleCodeExporter commented 9 years ago 
I like the idea of a separate tab for managing indexes (like foreign keys), but 
I'd like to retain the "this column is indexed" in the structure view. So in my 
above example, `id`, `account_id` and `key` would be highlighted in some way 
(but not `value` since it's only available as a secondary when also querying 
`key`)

What prompted this was spending 20 minutes trying to figure out why a simple 
query was trying to use a tablesort, and of course I was joining with an 
unindexed column. So here, I was in the query view the whole time and it 
wouldn't have really helped. I put most of this stuff in my model declaration 
unit tests, but there are legitimate exceptions to having all x_id cols indexed 
so that's impractical for us.

Original comment by firehed on 20 Jun 2012 at 12:51

GoogleCodeExporter commented 9 years ago 
I think both the structure and indexes view need to be redesigned as a list not 
a table.
A table only works if all the data is uniform, but that's not the case here 
(eg. ENUM vs CHAR, muticolumn indexes).

A UI like in Things.app might be more fitting.

Original comment by schlabbe...@gmail.com on 20 Jun 2012 at 5:35

Attachments: