Re: Database designer

On Thu, Mar 1, 2012 at 8:23 AM, Dave Page <dpage(at)pgadmin(dot)org> wrote:

> Hi
>
> On Thu, Mar 1, 2012 at 4:06 PM, Guillaume Lelarge
> <guillaume(at)lelarge(dot)info> wrote:
>
> >> 2) Why does it take so many steps to add a column? Click the + icon,
> >> and choose a name, then right click and select a datatype
> >> (incidentally, some common types like "text" require additional steps
> >> to select from a dialogue, which still doesn't list things like array
> >> types or use the proper names for aliased types we use elsewhere),
> >> then right-click again if I need to add constraints, and right click
> >> *again* if I then want to rename the constraint.
> >
> > I agree it would be better to not have all of this. This is something I
> > want to work on, but didn't find the time yet. My main idea was to add a
> > properties widget to handle the properties of table (and columns).
>
> That's one idea. The main thing is to be able to edit everything in
> one place without having to repeatedly right click to change a
> different property.
>

The datatype dialog right now is just a very simple one and should be
changed, I agree that and in fact it was on the TODO list of the DD.
And the table property dialog was too in the TODO list and at the coding
time only the graphical behavior was added, we still need a properties
based dialog with table + columns properties and then we can remove or
improved graphical behavior.

> >> This should all be
> >> done using the existing "Add Column" dialogue.
> >
> > If you mean dlgColumn, I disagree. If you mean enhancing the current
> > dialog of DD, yeah why not. But I would rather much have a properties
> > widget to avoid the use of a dialog.
>
> I'd be OK with a suitable properties widget - certainly if we used the
> dialogue some elements would need to be hidden/disabled... but, if we
> use a dialogue to put everything in one place, it makes sense to use
> the same design we already have as it aids user experience by
> presenting them with a consistent, familiar interface.
>
> I agree with you, but at the beginning I wasn't clear about the behavior
of the user interface, I was focused in other features and the UI behavior
wasn't a priority, and I agree that this should be fixed with an all in one
dialog as you suggest.

>
>
>> Similarly, the Tables
> >> properties dialogue should probably also be used to edit entire
> >> tables.
> >>
> >
> > Not sure what you mean here.
>
> To edit table-level stuff (name etc), we should also use the existing
> dialogue. Or a properties pane. Again, for consistency.
>

this related to last answers, and I agree it, with a very similar dialog
probably with some extra DD related properties.

> >> 4) Columns and tables have "default" names when you create them, which
> >> is inconsistent with the rest of the application.
> >>
> >
> > If the "rest of the application" is the browser, well, the DD is another
> > tool and may require any behaviour. But we can get rid of the
> > autonaming, I have no issue with that. BTW, we already use autonaming
> > for the autoindex of an FK.
>
> DD is part of the same product, and should be consistent in design
> with the rest of the product. I consider the autoindex name to be a
> little different - a) it's something users normally won't want to
> change, and b) it's based on the name they did enter themselves - it's
> not a meaningless default.
>

Autonaming can be turn off, but the idea of adding this feature arises from
good database design practices and the idea of having an initial default
name for it, if the user don't want to use, just overwrite it and it
automatically turn off.
Just to clarify, What's the suggestion for it?

>> 7) Why do we have to specify a short table name?
>>
>
> You're not required.

OK, let me rephrase. Why am I asked for one? What effect does it have
> on the generated schema?
>

Is for the use of autonaming feature. If that feature is turned off it
shouldn't be need any more.

>
> >> 8) Why do I have to select a table before I can add a column to it for
> >> the first time, but to modify it (except to add a relationship) I can
> >> right-click and existing column? Seems partially related to 6).
> >>
> >
> > Not sure why Luis did it that way. The advantage I see is that I don't
> > need to have multiple levels of dialogs.
>
> I can't see that it would require any difference in dialogues. I'd
> still need to name the column, but otherwise it just requires me to
> add the first column in one way (by clicking the table), while
> subsequent ones can be added in the same way, or by right clicking.
> Why can't I just right-click for them all?
>

It can be done, as I said before UI behavior wasn't my priority at that
time.

> >> 11) Somehow, I managed to "minimise" a table, so that only the primary
> >> key column is shown. I have no idea how. Clicking on what now looks
> >> like a maximise icon that's appeared doesn't fix it (though the icon
> >> does change to what looks like a minimise icon). The relationship
> >> lines still render as if the table was the original size, even if I
> >> move a table to force it to redraw.
> >>
> >
> > I didn't remember we could minimise/maximise tables, but seems a good
> > idea anyway. Need to fix the bug though.
>
> It does seem reasonable, yes - especially for wide tables with lots of
> columns. It should be more obvious how I did it though (or how to do
> it).
>

You can doit by two ways: minimize button and dragging table border (size
icon) from the button. It sounds like a bug, normal behavior is just like a
window with maximize/minimize buttons, I'm not sure about your problem, can
you give me the steps to reproduce it, probably is a bug.

> >> 13) There is a "Preferences" menu. Why isn't the existing Option
> dialogue used?
> >>
> >
> > Because it was easier for Luis to do it this way, and finish his project
> > on time. I failed to find time to fix this, even if it's something I
> > want to do.
>
> Hmm, AKA: not ready to commit!
>

> >> All in all, I'm pretty disappointed. As it stands, this feature seems
> >> to need a lot of work to get it to a standard that I'd be happy to see
> >> in 1.16 :-(
> >>
> >
> > Yes, it still needs some work. Most of your complaints are valid, and
> > are known at least to me. I wanted to work on them earlier, but failed
> > to find the time to fix them. Anyway, most of them aren't difficult.
>
> Good :-)
>
> > Kinda funny that, at the same time you sent your email, I had Luis on IM
> > telling me he wanted to continue his work on the database designer.
>
> Also good - we need to get this sorted out prior to release to avoid
> having to remove such a valuable feature.
>

I really don't believe this feature should be removed, it should fixed I
agree, but is a good designed feature, very flexible, able to do it things
that other databases designer (even comercial ones) aren't able to do it.
I'll work on it but now I'm working and I'm able to use only my spare time
to do it, but I'll make my best effort to finish in a professional way this
feature. I'll start to work on some of your suggestions at the end of the
week.

Regards, Luis.