Re: A little more meat this week


"dawn" <dawnwolthuis@xxxxxxxxx> wrote in message
news:1139380926.247941.27230@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

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.

LIST can display "nested data" in-line with the base data, but you are
limited to the viewing medium. If the idea of LIST was transposed onto a
multi-element viewing medium, like a windows form with several linked data
grids, then you could view whole groups of multi-dimensional data using a
single plain-english statement. The same idea fed through SQL would look
horrifying in comparison. The statement would look horrifying, that is.


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.


Simplifying for the computer is typically due to end-user performance
limitations or requirements. I don't know of many database developers or
designers who strive to make the user or end-developer become a nut-case.
That's not to say that there aren't many database designers who can spend a
day trying to sort a bag of white marbles by color(colour). You can have a
pretty database to look at and use, but it might just be the slowest piece
of doodoo you've every used. That, of course, is totally dependant on the
database environment and all the underlying technology. It's really
interesting to see your POV on things like this.


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


The model of what? The data? Does that _really_ matter, if you also don't
care about how is derived? I mean c'mon. You're saying the model of the data
is more important than the whole solution, in this argument. I totally
disagree. If you show me a clustered MySQL server with a PHP admin
front-end, I'd probably laugh at the limited peripheral aspects of MV and
it's VME. That's solely based on the data model in conjunction with the
environment that is required to run it! You can't look at the data model and
not pay close attention to the environment it will be located.

Glen


.

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: A little more meat this week
    ... 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 ... for a s/w developer and a s/w developer simplifies for the end user). ...
    (comp.databases.pick)
  • 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: Append Query Problem
    ... Completed all steps including importing into a blank database. ... It is not an attached table, linked to a back end that is missing. ... If you are still stuck, see if this query returns your linklist table: ... there are 2 internal canonical lists of tables. ...
    (microsoft.public.access.queries)