Re: A little more meat this week


Kevin Powick wrote:
It's interesting that you say "..while we can get a lot of different
result sets in an SQL query, we cannot get a single web page of data if
said data includes lists."

You go on to say "The inability to get a view that is not normalized is
a failure of SQL-DBMS tools"

Whether or not I agree with the above sentiment is not the point of my
reply. Instead, I wonder if you are implying that MV databases are any
better in this regard?

I wasn't actually intending to imply anything specially about MV
databases in this blog although they do have a data model that would
permit a similar data model as the other interfaces mentioned, and I
will bring that up in a subsequent blog. I am talking more about the
RM and non-DBMS-related data modeling.


I would say they are not. I am not currently aware of an MV
implementation with a query processor capable of returning a result set
at all. AFAIK, the only thing possible a MV query can return is a list
of record keys.

You can definitely use the query language to return a result. LIST ...
entered at the colon prompt returns a result to the screen, hold file
or printer, for example. If you are suggesting it is not a set because
you can have duplicates, then we can call it a result bag (SQL
resultsets are bags too). If it is a lack of set processing functions
or using the output of one query as the input to another function,
these are features of whatever tools are used. My specific interest
right now is in the data model. I would not at all claim that the
exact features of a typical MV system today are the perfect set of
features.

Once we are free to move forward without being constrained by the RM
and SQL, we can look at how to get the best features.

From this list of keys, it takes a lot of processing to extract the
data needed to populate your hypothetical web page.

Again, I'm looking at the data model and not database tools at this
point. If I think about it, however, it seems that a single query
against a logical dictionary (that might have complex code behind
virtual fields) could show the data for a single page like this. The
shape, or model, of the data is compatible. You don't have an
impedence mismatch to the extent you have with the RM. I'm interested
in the future of databases and not restricting ourselves to SQL (e.g.
3VL) and the RM (1NF, in particular) when there are more useful data
models such as those used with Pick, XML, JSON, or the WWW (each of
these similar, but different from the others).


Leaving MV out of it, I can't understand how you think that the
inability of a database tool to provide you with all the information
you need to populate your hypothetical UI via a single query is somehow
inept.

I was talking about modeling the interface, whether between processes
or between a human and process (UI). A SQL View cannot be used to
model the interface. I don't care whether this relates to a database
or data in memory or whatever. This particular blog is not about the
database. I'm not at all talking about the database providing me with
something. I'm simply talking about modeling data. That is something
that is done throughout software development, not just reserved for
working with databases.

Where do you draw the line when it comes to complexity?

Simplify for the "user" (for example, a database developer simplifies
for a s/w developer and a s/w developer simplifies for the end user).
Those designing databases sometimes think they should simplify for the
computer rather than for their user.

At
some point, a UI web page for example, will be sufficently complex that
no data tool/query will be able to satisfy it with a single result set.

The question I'm asking is how you model data in the s/w development
process for all sorts of purposes -- for UI's, web services or any
other interface. Whether a screen view "comes from" a database is not
the point -- the point is about what the model looks like. Can it be
modeled using the RM (that's where I brought in SQL although I know
that SQL is not exactly the RM). Did that clarify? --dawn

.

Relevant Pages

  • Re: DBMS and lisp, etc.
    ... Naively implemented with SQL, again for 10 ... (1 query for the initial orders, 1 query for each order for its ... soon as you upgrade to the SQL database. ... (eq (order-customer orderA) ...
    (comp.lang.lisp)
  • Re: complex filter and calculations in access
    ... switch to SQL view. ... query by switching to datasheet view, ... of your database using the from address in this post. ... pre-op infections yes/no ...
    (microsoft.public.access.queries)
  • Re: complex filter and calculations in access
    ... when using a subquery on the same table as the main query, ... switch to SQL view. ... of your database using the from address in this post. ...
    (microsoft.public.access.queries)
  • Re: A little more meat this week
    ... said data includes lists." ... implementation with a query processor capable of returning a result set ... then we can call it a result bag (SQL ... I'm looking at the data model and not database tools at this ...
    (comp.databases.pick)
  • Re: dbdebunk Quote of Week comment
    ... > a lot of really bad SQL programmers. ... But SQL does not have a pointer data type or the ... > being told to design a database. ... But why is little Cindy Lou Who employee ...
    (comp.databases.theory)