dbTalk Databases Forums  

Re: Dreaming About Redesigning SQL

comp.databases.pick comp.databases.pick


Discuss Re: Dreaming About Redesigning SQL in the comp.databases.pick forum.



Reply
 
Thread Tools Display Modes
  #1  
Old   
Seun Osewa
 
Posts: n/a

Default Re: Dreaming About Redesigning SQL - 10-18-2003 , 04:47 AM






Be careful, Christopher, or Bob might just turn on you!

Christopher Browne <cbbrowne (AT) acm (DOT) org> wrote

[snip]
Quote:
Nobody seems to have been prepared to explain the MV model in adequate
theoretical terms as to allow the gentle readers to compare the theory
behind it with the other theories out there.

I'm afraid that does not reflect very well on either those lauding MV
or those trashing it.

- Those lauding it have not made an attempt to show why the theory
behind it would support it being preferable to the other models
around.

I hear some vague "Oh, it's not about models; it's about language"
which doesn't get to the heart of anything.

- And all we get from Bob Badour are dismissive sound-bites that
_don't_ explain why he should be taken seriously. Indeed, the
sharper and shorter he gets, the less credible that gets.

There are no pointers to "Michael Stonebraker on Why Pick Is Not My
Favorite Database." Brian Kernighan felt the issues with Pascal
were important enough that he wrote a nice, approachable paper that
quite cogently describes the problems with Standard
Pascal. <http://www.lysator.liu.se/c/bwk-on-pascal.html> He nicely
summarizes it with 9 points that fit on a sheet of paper.

If Bob wanted people to take him really seriously about this, and
has done all the research to back up the points that are apparently
so obvious to him, then it should surely be _easy_ to write up "Nine
Reasons Pick Isn't My Favorite Database System."

And just as people have been pointing back to Kernighan's paper on
Pascal for over 20 years, folks could point back to the "Pick"
essay.

But apparently it is much too difficult for anyone to present any
_useful_ discourse on it.

Reply With Quote
  #2  
Old   
cmurthi
 
Posts: n/a

Default Re: Dreaming About Redesigning SQL - 11-06-2003 , 10:32 AM






cdp.pick: Talking about RVAs (sung to the tune of Talking about my
generation..joyfully, one hopes...):

andrewst wrote:
Quote:
Originally posted by Mike Preece

Jonathan Leffler <jleffler (AT) earthlink (DOT) net> wrote in message
news:<Jy0qb.549$Z25.266 (AT) newsread4 (DOT) news.pas.earthlink.net>...

Mike Preece wrote:

They have, kind of. But being market driven they have done it as
part of making their DBMSs "object oriented". For example, Oracle
lets you do this:
CREATE TYPE phone_info
( phone_no VARCHAR2(20)
, phone_type VARCHAR2(1)
, phone_preference VARCHAR2(1)
);

CREATE TYPE phone_list AS TABLE OF phone_info;

CREATE TABLE person
( person_id INTEGER
, person_name VARCHAR2(35)
, phones phone_list
);

INSERT INTO person VALUES
( 123> , 'Andrews'
, phone_list( phone_info('123-123 1234', 'H', 'E'), phone_info('123-456
7890', 'W', 'D') )
);
If you accept this, you should embrace the mv concept in Pick. We just
don't have the nice syntax.

However, the point seems to be RVA's 1) were 'anointed' acceptable by
the relational gods sometime in the near past 2) are not universally
accepted (or maybe disdained?) and 3) Oracle at least has implemented
them in a nice, easy-to-understand syntax. Where's the beef?

In a previous post, it was implied that RVA's are more complex than
mv's. It is true that normally mv's contain only data, but the data
could be a foreign key or for that matter anything, so the distinction
seems moot. The main difference I see is that the structure of the RVA
is explicit in the CREATETABLE and therefore integrity is maintained by
the dbms. In Pick, only the best RAD's do something similar (and, for
what it's worth, this inability in most Pick RAD's to structure the
RVA-equivalent has been my constant complaint over the years.)

Normally the individual mv's are just that-individual fields (phone_no,
phone_type and phone-preference in the example above)-and the integrity
relationship is procedurally maintained. That said, such maintenance is
pretty easy and clear in the procedural language, mvBasic.

eg: for an Insert:
PersonRec<PhoneNumber,-1> ='123-123 1234'
PersonRec<PhoneType,-1> = 'H'
PersonRec<PhonePreference,-1> = 'D' etc.

Quote:
I may not have the syntax quite right, I never actually do this, but it
is right in principle
Do you not do this because you disagree with the principle?

Quote:
1) List Persons Name with PhoneNumber "12345"
and
2) List Persons "Mike" PhoneNumber
i.e. syntactically different:

List <table> <attribute1> with <attribute2> <value
and
List <table> <Value> <attribute2

In SQL:

select person_name from person_phones where phone_number='12345';
and
select phone_number from person_phones where person_name=Mike';
i.e. in both cases:

select <attribute1> from <table> where <attribute2> = <vaue>;

But you could just as easily say in Pick:

List PhoneNumbers Name with Name "Mike"

which makes it the same syntax as 1)

Chandru Murthi



Reply With Quote
Reply




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.