Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!uakari.primate.wisc.edu!indri!ames!pasteur!xanadu!larry
From: larry@xanadu.uucp (Larry Rowe)
Newsgroups: comp.databases
Subject: Recent postings to comp.databases...
Message-ID: <15963@pasteur.Berkeley.EDU>
Date: 31 Jul 89 22:02:07 GMT
Sender: news@pasteur.Berkeley.EDU
Reply-To: larry@xanadu.UUCP (Larry Rowe)
Organization: Postgres Research Group, UC Berkeley
Lines: 61

i haven't been reading this newsgroup for the past couple of months
and i just spent the past 2 hours catching up.  i have several comments
on recent postings.  (for those of you that i haven't met yet :)!, i'm
one of the professors at Berkeley that started rti. mike stonebraker
and i are currently working on next generation dbms's (postgres) and
application development tools (picasso, formerly objfads.)

1) fetch previous
the relational model has nothing to say about application program interfaces
(API) to databases.  cursors are an API abstraction.  mike and i wrote a
paper several years ago that proposed a new API abstraction, called a portal,
that attempted to fix problems that we ran into trying to implement browsing
style interfaces to dbms's.  cursors are essentially sequential access
abstractions to a query result.  what a browsing style interface wants
is the ability to randomly fetch data from the query result.  moreover,
the fetch should be able to return more than 1 record.  if you have a table
on the screen and you want to scroll forward, it seems wasteful to issue
N ``fetch 1 record'' instead of one ``fetch N records.''  Portals allowed
fetch forward/backward and they also allowed you to say ``fetch N where P''
where P is a predicate that is used to search in the return set.  this
last operation can be used to implement ``scroll forward to the row in
the table with name = "Smith".''

most dbms's don't implement backward fetches because they don't have 
backward pointers on their disk pages.  remember that the previous page
may be an overflow page added between the previous main page and the 
current page.

another serious problem is that the demand for SQL compatibility for
commericial products is stiffling inovation at least for now.  it'll
probably be a couple of years before the vendors start to put truely
creative things into their SQL products.

2) normalization
donovan hsieh had it right when he said that you have to pay attention
to both consistency *and* performance.  i have seen too many people fail
when building applications on relational dbms's because they were too
restrictive in their thinking.  they weren't willing to denormalize their
db designs to meet application performance requirements.

3) referential integrity
every commercial SQL dbms will have implemented simple referential
integrity by this time next year.  sybase already has it implemented
and ingres and oracle will do it in the next release.  the point that
someone mentioned about rti doing more general rules, relates to
a point we have been making.  referential integrity is fine, but it
is only one kind of integrity rule that you might want to put on
your data.  general purpose rules in a data manager allow you to 
have the dbms maintain many other kinds of constraints.  the toy
example that we use is to represent the type of desk that an employee
should get.  emps under 40 get a steel desk, emps over 40 get a wood
desk, and the president gets a wood desk irrespective of age.  you
could represent this information by storing the value "wood" or
"steel" in a column, but this representation would get out of date
over time.  by storing the information as a rule, the dbms manages
the information.  of course, what you also want are database alerters
(i.e., asynchronouos commands to programs generated by the dbms)
so you can automatically issue the instructions to the facilities
people to change a person's desk on his/her 40th birthdate.

	larry