Re: Onto a potential relational manipulation language

[Snipped]
> Cimode, from your past posts, I seriously would not consider it likely
> that you would consider most subsets of SQL.  And I wouldn't blame you!
>   (UNLESS the subset of SQL were so small as to include merely an SQL
> keyword written as 'KEY'!)
And you guessed right.;)

I long hesitated to use only NATURAL only (vs TOTAL for superkey). I may just correct this. Thanks.

> I can't comment on the syntax because i) I don't think one can get very
> far with a syntax without seeing quite a few examples and
Feel free to name a few, I can then tell you if they are coded or how I would. For the moment only basic relation operators are covered.

> ii) I don't
> know the scope of your db's features.  By 'scope' I mean how far it goes
> toward capturing the usual physical suspects - concurrency, recovery and
> so forth.
All non necessary RM orthogonal are not in the current scope. The system only allows to define, operate and present relations in primitive way that is as inspired from ra as it is from relational calculus.

> I mention this because I saw the word 'PERSISTENT' in the
> example.  If I were making up a syntax, I'd start by naming shortcuts
> for expressions based on some formal logic.  The one closest to my
> thinking would be D&D Algebra but there are others, don't ask me how
> many, such as Vadim's RL.
PERSISTENT (by lack of a better choice in my limited english vocabulary) is just a word to leave open the possibility for the programmer to have some control over the physical representation of relation on disk. They are opposed to DERIVED relations (sections) where relations are purely have no physical r to be compiled and. I found UNDERIVED to be unintuitive but that may just be plain wrong.

> Personally, I even separate persistence from my preferred (admittedly
> very narrow version) of the essential RM is and think of it as a
> physical phenomenon and quite orthogonal to the minimum scope of a db.
Although I do recognize that essential RM is orthogonal to physical layer, I do not see any other way of implement an rm compliant computing model than to implement independence. Without insuring some basic coherence between the storage logical mechanism and the need for relation operation I do not see how one can achieve independence without dealing with both. Even a limited scope relation operator.

> I know lots of people who think it's crazy to have a db that's here
> today and gone tomorrow, but it doesn't bother me.  In fact, I remember
> many db's that I wished would just go away.
I am still far from calling it a db system.

> I even view types or domains as orthogonal in the sense that I don't see
> why a minimal implementation of an algebra needs to know how to
> construct them.  
How would you then implement a truthful relation constraining mechanism otherwise than by making use of domains (or unconstrained sets) ? As far as I am concerned, both equate, just depends when.

> All it really needs is some other implementation to
> tell it when two values are equal (the 'other' implementation could even
> change its answers from day to day in my view).  
Think about the following: how many built systems know how to deduct/ operate the following (apologies for the notation)

R1=[{1, A}{2, B}{3, C}]
R2=[{B, 2}{C, 3}{1, A}] --> order independent

in the following elementary ways...

R1 + R2 = R1 = R2
R1 - R2 = R2 - R1 = [0]
R1 * R2
R1 INTERSECT R2 = R1 = R2 and so forth...

I believe somehow that programming such system to operate logically the above can bring back RM to its essence: math.

> I don't think this
> denies the chance to have user-defined types, it just means that I would
> start with the most minimal features and syntax possible and build from
> there, that way  after adding another 'suspect', I could revisit all my
> previous jumping-off points to see if their answers remained what I
> intended.
I somehow believe that too much emphasis was put on relational algebra and not enough on relations themselves. The fact that a relation *de facto* constitutes a user-type or a domain of potential value is an advantage that should be used to get rid of unecessary semantic grammar to operate relations. For instance, I do believe that the transcription of the operational JOIN as a symbolic ra operator was not such a good idea after all. Why make use of repetitive/redundant JOIN semantic operators when one could simply state a type and allow the subsystem make the deduction as to whether or not references are to implemented at runtime (being an N-ary relation)?

IMHO.;) Received on Tue Dec 09 2008 - 23:46:21 CET