开发者

A better design of this SQL query builder UI

开发者 https://www.devze.com 2022-12-20 22:45 出处:网络
I\'m in the process of redesigning a SQL query builder UI for a application that I use, well it\'s a third party app but has a plugin model so I wri开发者_开发知识库ting my own to replace the standard

I'm in the process of redesigning a SQL query builder UI for a application that I use, well it's a third party app but has a plugin model so I wri开发者_开发知识库ting my own to replace the standard one. One area I am not very good at when it comes to application design is the UI.

I would be really interested to see/hear how other people would layout this dialog, to make it a little bit better, or do you think that it is good as it is.

I am using WPF for my new design so I can be pretty flexible with the UI.

This is the current SQL UI: alt text http://img190.imageshack.us/img190/9492/sqlq.jpg

Just for clarity when you select a option from the Tables menu, it adds the table name to the "from Tables" text box, same with the Columns drop down into "Select Columns" box.


Who exactly would use such a UI? Since it's basically just a pre-defined SELECT statement template, I would expect such a tool to be used by people who know how to write SQL statements from scratch (since that's essentially what they're doing). The addition of available columns and tables and stuff like that is nice, I guess.

If the tool is meant to be used by experienced SQL users, the tool looks much too restrictive. For example, it appears that one would have to write his own JOIN clauses as WHERE clauses, making outer joins bothersome. It's much less useful than an open textbox.

If the tool is meant to be used by inexperienced users who might not know the ins and outs of relational database management systems, this thing is laughably awful. Too much needs to be done in spite of the restrictiveness of the tool. Too much knowledge of SQL is needed to understand what the form needs. It's more useful than an open textbox, but not much.

Ways to improve the tool depend on the end users. If they're experienced with SQL, the tool should be more of an open textbox where they can write whatever they want, including JOINs. Look at how Microsoft's Server Management Studio allows users to build queries: very nonrestrictive, with the ability to view tables and join them by dragging one column to another. That's a very natural way to approach queries in a visible, organized manner.

If the users aren't experienced with SQL, the tool should do a lot more for them. For example, if the user picks two tables, it should automatically join them so that he doesn't have to understand how joins work. Also, the comboboxes on the side should be able to work in any of the open text boxes, not just one specific text box each. Because you need column names in the SELECT part as well as the WHERE part.

Just think about your userbase, and tailor to the tool to them.


Makes perfect sense if you know how to write SQL.

I would consider perhaps moving the Tables-Columns-etc dropdownlists closer to where their contents will be displayed. You could even incorporate them with the left captions for the textboxes. So, for example, where your text says "Select Columns", you could put the Columns dropdownlist in that spot. Then the default selection there could be .

I think it's a nice UI, though.


What about joins?

What is the point of trying to redesign it? Query analyser has one of the best UIs in that it is unobtrusive and lets you do what you need.

I think if you try and shoehorn statements into a format this will not always work but may work in the majority of cases.

It depends on the business requirements really.


A better UI would be to show all the tables, fields in a tree view with check boxes. Trapping the click-event, one can easily aggregate the SQL.

0

精彩评论

暂无评论...
验证码 换一张
取 消