Re: Database designer

On Thu, 2012-03-01 at 16:23 +0000, Dave Page 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.
>

There is no standard properties widget for 2.8. There is one available
with a wxWidgets licence, not sure I want to start working on adding it
to the pgadmin code. And 2.9 has this widget. Probably we'll start with
a simple dialog, better than the current one, and use the properties
widgets of 3.0 when it'll come out (their roadmap says summer 2012, but
it keeps getting postponed, and anyway, even if they do release it in
2012, it will be too late for 1.16).

> >> 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.
>
> >> 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.
>

I understand your point of view. But using dlgTable and dlgColumn would
be kinda weird. All you can set in DD for a table is its name and
columns. We would have to disable so many widgets that I don't see the
point of doing this. The same applies to columns and constraints.

> >> 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.
>

It is a different tool with a different aim, mostly a graphical view of
a database. Such differences may force us to use different dialogs.

> >> 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?
>
> >> 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?
>

Well, as I already said, you only have name and columns for table. In
DD, you cannot set its owner, its schema, its tablespace, its fillfactor
and so on. If we had to use the dlgTable dialog, we would have to
disable six tabs, and hide the SQL tab (which doesn't mean anything in
this context). We would have to disable some of the widgets in the first
tab, we would have to allow only the creation of primary key and foreign
key (no check and exclude constraint). Not sure such a big dialog with
only that few widgets would be such a great idea.

On dlgColumn, we would need to disable three tabs and hide the SQL tab.
We would also need to disable many widgets on the first and second tabs.
A bigger issue is the type combobox. Right now, we only allow to fire DD
with a connection to a database. But I think many people will like to be
able to use it without having an established connection. One reason
would be that it would help them to be sure they don't really change
their database. So, we'll have to allow its use without a connection to
a database. In that specific case, how will we handle the setting of a
column's type? My first idea was to use a simple textbox where a user
can enter anything he wants. But it can make things harder. How will we
handle issues like "this-type-doesn't-exist-in-my-database"? do we
really have to care about that? I have no good answer to that yet.

--
Guillaume
http://blog.guillaume.lelarge.info
http://www.dalibo.com