[Phpmyadmin-devel] GSoG 2011: Reg Zoom-search idea

[Ammar Yasir]

On Sun, Mar 20, 2011 at 3:54 PM, Marc Delisle <marc at infomarc.info> wrote:

> Le 2011-03-20 06:14, Ammar Yasir a écrit :
> > On Sun, Mar 20, 2011 at 3:02 PM, Marc Delisle <marc at infomarc.info>
> wrote:
> >
> >> Le 2011-03-19 17:35, Ammar Yasir a écrit :
> >>> On Sun, Mar 20, 2011 at 2:00 AM, Marc Delisle <marc at infomarc.info>
> >> wrote:
> >>>
> >>>> Le 2011-03-19 15:13, Ammar Yasir a écrit :
> >>>>> Sir,
> >>>>>
> >>>>> I looked at the table search page. One problem I find is that a form
> >> such
> >>>> as
> >>>>> table search page consists of all the columns. I think in general a
> >> user
> >>>> is
> >>>>> interested in at most 2-3 criteria for searching at once. If number
> of
> >>>>> columns are more(in a table eg. users table in mysql database), the
> >>>> search
> >>>>> table form will contain lot of irrelevant fields(to his query). Can
> the
> >>>> page
> >>>>> be something like it asks the user to select the column first, then
> its
> >>>>> detail and then again a column if he wants to build the query
> further?
> >>>>
> >>>> (Please do not top-post, conversations are difficult to follow).
> >>>>
> >>>> I was referring to the Table Search page because we'll have to avoid
> >>>> duplicating the same functionality on many pages.
> >>>>
> >>>> You are right, the table Search page displays all the columns in
> "query
> >>>> by example" but in its Options hidden panel you can choose the columns
> >>>> that will be displayed. I think that this behavior could be improved
> by
> >>>> adding a way to quickly hide or show which columns are to receive a
> >>>> search criterion.
> >>>>
> >>>> I think that we can reduce some fields by combining elements from the
> >> table
> >>> search page and those from the options hidden pane. The table search
> form
> >>> provides appropriate operations for each column and in options panel we
> >> can
> >>> select columns but it just provides a textbox to enter the body of the
> >> WHERE
> >>> clause.
> >>>
> >>> As in this case we are only interested in selecting one of the columns,
> >>> initially we can just have a list of columns and then when a user
> clicks
> >> on
> >>> one of the columns, the appropriate operations available for that
> column
> >>> appear. This reduces some of the fields on the screen.
> >>
> >> This should work but the user needs to select two columns, not just one.
> >>
> >> We can put a constant on the number of search criteria to 2, so you'll
> have
> > to select exactly two columns.
> >
> > One more thing, can the two columns be from different tables also. Like
> for
> > example, for a house auction database:
> > There is a 'house' table (neighborhood,address,no_of_rooms,plot_size....)
> > and a sales table (selling_price,date_sold,....)
> > and the user might want to see a visualization of plot_size vs
> > selling_price.
> >
> > Do you think I am going off the project idea? This would involve using
> > underlying relationship between the house table and sales table and it
> would
> > be fairly complex to develop such system.
>
> Yes it could. I'm not saying that this project has to support this,
> however.
>
> Do you know about the multi-tables query generator? You click on a
> database name, then Query. This has been there for many years and in
> version 3.4 there is a visual mode. This feature generates the
> multi-table query, based on existing relations (only from internal
> relations, sadly not yet for Innodb-style relations, see FAQ 3.6).
>
> I totally forgot about that feature. This interface can combine well with
visualizing query results spanning multiple tables.


> Can we conclude that whatever way is used to generate the query, the
> zoom-search mode could be used when we have a results set containing two
> columns?
>
Yes, I agree with this. So for the visualization part, there is one point
mentioned that when we zoom in for example in the movies database case we
see the movie's title. How is that to be decided that what label to show for
a point? Should the user input this or does the system comes up with a
label(like a key for each point)?

Also, I submitted a patch for mass table prefix change. May someone look at
it and confirm? I had made changes to the original patch but I didn't get
any comments further.

Regards,
Ammar Yasir

>
> --
> Marc Delisle
> http://infomarc.info
>
>
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> Phpmyadmin-devel mailing list
> Phpmyadmin-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.phpmyadmin.net/pipermail/developers/attachments/20110321/b8d15695/attachment.html>