This week my blog is more left-brained than last week. It might not be
as entertaining, but I'm very pleased with it. I don't see how any
logical person who understands what I wrote could disagree with it, but
I might be delusional.

www.tincat-group.com/mewsings

Enjoy --dawn

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


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. Where do you draw the line when it comes to complexity? 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.

--
Kevin Powick

Kevin Powick wrote:
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.

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

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.

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.

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

dawn wrote:

All it clarified for me is that you live in a different world than I
do. :-)

You're obviously an intelligent, educated woman, that would excel in an
academic environment. Not to imply that you don't already excel at
whatever it is that you do.

I guess I'm more of a "get it done" type of person. I quickly tire of
long, philosophical and often circular debates that, while sometimes
thought provoking, don't actually help a simple guy like me get
anything done.

I think I'll stick to replying to technical questions for which I may
have a helpful answer.

Cheers,

--
Kevin Powick

Dawn,

You may appreciate this link (and also the "more information" link),
which I obtained from the raining data website
http://www.computerworld.com/databas...107715,00.html
(talks about limitations of SQL/Oracle vs XML/xQuery in some situations)

......

I'm not sure where to put this or even if it's germane. Maybe my head
is still swimming with .NET commentary.

..NET components, especially with v2.0, have a datasource property to
which you can assign any object which implements an appropriate
interface. (In English: you can hook data to a lot of controls.)
This isn't new by any means but the neat thing is the diversity of
objects which qualift as a valid data source. You can create a SQL
datareader, hook it to a control, then pass it a command and fill it.
That same object can be the source for a listbox, grid, etc. Because
..NET is so strictly data-typed, as is the RM, if you connect a SQL
resultset to a grid, the grid automatically renders using appropriate
controls - so a Boolean value will render as a checkbox, for example.
Maybe this is the sort of thing you've been looking for?

In addition, you can use XML (or Web Services returning XML) as the
source of a grid with the same results. And you can specify a custom
class as an ObjectDataSource, which means you can define a class any
way you want, populate it any way you want, and at rendering time all
of the properties are polled and properly rendered. Of course all
auto handling can be overridden. Is this any closer to what you're
looking for?

HTH
T

Tony

The .net databinding possibilities are superb... agreed.

Though from Dawn's perpective, this is in the presentation layer, rather
than in the database design itself.

Dawn is looking at this from the data-model persepctive. I believe in a
nutshell, her stance is that 1NF database methodology, coupled with SQL as a
standardised query language doesn't really apply itself to the presentation
requirements that are needed today.

This is perhaps evidenced by the fact that dotNET allows so many other
objects to be "data-bound" rather than straightforward datasets populated by
SQL.

Is this a representation of failure of SQL to provide the information?

If you follow data-binding methodology in pre-dotnet versions of Microsoft
products (vb6 for example) you will note that whilst it all looked good in
concept (binding using ADO and sql) it really didn't work well in the "real"
world.

I hope that I've not paraphrased either Tony or Dawn incorrectly in my
reply. All normal caveats apply!

Regards
Simon
"Tony Gravagno" <g6q3x9lu53001 (AT) sneakemail (DOT) com.invalid> wrote