Frank Schönheit - Sun Microsystems Germany wrote:
Well, the "single file" database implemented by means of the HSQLDB
engine targets exactly the people who don't care for this distinction.
We implemented this because we think those people are important, and the
"Queries in Queries" feature is also targeting those people.
People knowing the distinction are probably equally good served with
views, since they allow to solve the same problems (perhaps after we
made views editable, which is difficult, since there is no common way
supported by even only a majority of DBs).
Alright Frank,
I wholeheartedly
agree that ease of use is a major goal. I am not sure that limiting
options is always the best way to attain that goal, but it is always
something to look at.
For the moment however, let's just look
at the 'query as view' approach. As you propose in the requirements
document dropping of UI support for view creation would limit options
presented to the user. An immediate benefit is that any query can be
incorporated into any other query. In this regard then yes, you have
added a capability not currently offered, or have you?
Right
now If someone creates a query and wants to use that query in another
they must perform one action - convert the query to a view. This
action requires the use of nothing more then a single context menu
choice. So what have you actually eliminated? One mouse click for the
menu, and one mouse click for the dialog box that follows. I suppose
you have also removed a term, 'VIEW'.
A major draw back to
doing this in the current release of Base is that once converted the
definition of this view can not be altered. Although I have not
checked it would surprise me if this definition is not actually
stored in a HSQL system table, and therefore adding support for
altering it should be fairly straight forward. In essence one will no
doubt still be dropping and re-creating the view, but this two step
process could be hidden from the user. Further the query designer
could be updated to read the defintion from the system table and
display it to the user for alteration.
At this point of course
one could argue that this update to the query designer, support for
altering views, would be beneficial whether one switched to 'query as
view' or stayed with 'view as view'. Therefore he effort needed to
add this functionality is neutral as to a reason for or
against.
What of any side effects however. Two problems,
risks, with the 'query as view' approach come to mind. The first is
related to the HSQL engine itself. I believe that when a view is
created there are optimizations and constraints added to the schema.
In the case of constraints this means that when a user attempts to
alter a table structure ( alter table command ) in such as way that
would affect the validity of the view the engine will recognize this
and disallow the execution of the command. In such a case one must
drop the view first, alter the table, then re-create the view. This
is I believe considered one benefit of using a view versus a select
statement.
Of course as things are today one might also alter
a table in such a way as to invalidate a stored query. In this later
case however, the query definition is still available. When the user
is notified of the error at run time, they can open the definition
and alter it as needed. If a switch is made to store queries as views
and therefore the definition of the selection statement is now stored
in the system tables, when the view is dropped to allow that alter
table command, it's definition is no longer available. One would need
to recreate the definition from memory, or Base would need to supply
yet another layer of storage - perhaps using a 'current query'
structure to temporarily store this information.
The second
problem I forsee is support for parameterized queries. I will simply
ask how that would be done using a view?
Sincerely
Drew
