Re: Some Hype on "new" databases - where's the theory in this group?

Alfredo Novoa wrote:

> ...

>> i've never seen any discussion of such basics in this 
>>'theory' group.  how come?  isn't this the kind of thing that should be 
>>discussed here?

thanks for comments. now that i've opened my big mouth, i guess i'm obligated to reply. i've forgotten exactly what they all were but one of them goes something like this. (i was interested in comparing <OR> and <AND>, not that an engine would depend on both, but so that it could use one of them plus <NOT> to check the other one, in other words to be able to check some of its own logic):

TTM page 56 - manual check of meaning of <OR>         

Check R1{A,B} <OR> R2{B,C}

where the domain of A is (1,2,3) such that 1=1, 2=2, 1!=3 and so forth
and the domain of B is (1,2,3,4) et cetera
and the domain of C is (1,2,3) et cetera

then
{{1,1},{2,2}} <OR> {{1,2},{3,2}}
=
{{1,1,1},{1,1,2},{1,1,3},{2,1,2},{3,1,2},{2,2,1},{2,2,2},{2,2,3},{1,3,2},{2,3,2},{3,3,2}}

at least, that's how i worked it out using de Morgan's law.

if i may continue, i believe that D&D characterized their 'ALGEBRA' as something of a "toy" and maybe they're right but i don't think that's been shown and i find it very appealing. to my eyes, it has the allure of being perhaps fundamental. stupidly or not, i am entranced with the idea of a small engine that would not be susceptible to 'bloat', the core of which would be maintainable by one person. i won't go into all my reasons for this just now but some of the notions i had in mind were:

1. i would hope it would have no knowledge of built-in domains other than it would need to bootstrap itself (it would rely on user domains even to decide equality - user domains would also provide what i think D&D call canonical representations. personally, i wouldn't care if domains, or user types if you will, could be altered or switched after the fact!).
2. when i say 'core' i'm excluding user interfaces. i mean, precisely, D&D's "ALGEBRA" although perhaps not all of it! (regarding interfaces, and IF i ever got around to making a "modern" one, at first, i thought of adapting openoffice but the idea of excising Java and XML from it distresses me. perhaps i would use Mozilla (not its so-called db support) and hold my nose regarding the XUL stuff which i admit is well-intentioned.)
3. it would be as declarative as possible. because of this, it might have to define numbers such as integers in some built-in way.
4. in my ignorance, i'm not bothered, at least not yet, by the "computational difficulties" of supporting <NOT>. given that we are talking computers here, then domains are finite in practice if not on paper. also, i don't see why a relational result cannot consist of the union of an intension as well as its (conventional) extension.
5. what really got me started along these lines, if i can use the word "started" to describe something that's just an occasional reverie, was trying to understand how far-reaching Codd's original operators were. i remember seeing that (with appropriate syntax and the help of immutable place-holders), the conventional verbs, INSERT and DELETE are expressible (i like to say inherent) with various combinations of <AND>, <OR> and <NOT>, as are foreign keys and candidate keys (although it was some years before my limited brain realized the latter). this may seem trivial to some but it was greatly encouraging to me as was Hugh Darwen's kind replies to some confused questions i put to him. further, i think TCLOSE might be avoidable but i haven't quite put my finger on exactly how, though i have in mind an approach i once saw which would involve using intensions.

i would hope that in the 'core' there would be no conventional procedural programs as such, given the number support that i mentioned, and i would implement conventional locking, ala Gray, as well as a presentation mechanism, at an unconventional level, in a layer above the core engine which might add verbs for convenience but would depend entirely on relations implemented in the 'core'.

(aside - one motive here was partly avoiding bloat, relying on as few concepts as possible and having an engine that's easier to validate as well as to maintain. i could care less if it ran sluggishly as that's the speed i do things anyway. besides, from what i've heard of today's   systems they spend a great deal of effort on aspects that i wouldn't call real/raw requirements. as for whether such an approach could scale to the so-called 'enterprise' level, i also don't care as i don't see that as a problem when it is a fact that a medium-sized airline in the 1980's could run a useful reservations database with 300 MB worth of persistent storage which today is a rather puny amount - i think the real enterprise problem is cultural / organizational and 'mindset'/choice of tools! a more airy-fairy motive had to do with automating application maintenance choices but i put that one aside given that the simpler notions above haven't even been demonstrated! i remember a friend trying to sell what was then a simpler development environment. the customer gave him a really hard time about not having this feature or that which their old product couldn't run without. he compared theirs to a hot air balloon and reduced their complaints to the equivalent of asking for a gondola to be attached to the jet fighter.)

well, i've gone on and on and still left lots of details unsaid, but for what it's worth, i think that's enough. whether it explains my earlier comments, i don't know but perhaps it at least hints at my motives.

pc                   Received on Sun May 08 2005 - 19:40:43 CEST