Re: What databases have taught me

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Sat, 24 Jun 2006 02:04:58 GMT
Message-ID: <e51ng.1360$pu3.36484@ursa-nb00s0.nbnet.nb.ca>

Keith H Duggar wrote:

> Bob Badour wrote:
>

>>Keith H Duggar wrote:
>>
>>>Interesting. Since you still use Java have you taken a
>>>look at Rel?
>>>
>>>http://dbappbuilder.sourceforge.net/Rel.html
>>>
>>>What are you thoughts on it?
>>
>>I know you asked Marshall and not me. I didn't understand
>>some of the changes to the language like, for instance,
>>the requirement for BEGIN/END for the WITH statement. A
>>lot of the other additions seemed like syntactic candy
>>that don't add functionality -- just complexity and
>>language redundancy.

>
>
> Oh I'm sorry, I never mean to exclude anyone from answering
> any of my questions. Just the writing sometimes seems more
> natural to me if directed towards a single person. Thank you
> for your input.
>
> I'm less curious about specific language designs and more
> curious about I guess architecture and library issues. For
> example Rel incorporates a complete DBMS implementation. And
> the most recent experience I had with a DBMS (DB2) was using
> the usual client/server architecture to submit queries while
> most of the analytical computation was actually done in Java.
>
> All that seems a little to heavy for what I want to do; that
> is incorporate relational concepts and thinking into my tools
> and simulations. I'm looking for a way to develop stand-alone
> apps where the relational code operates directly on the data
> structures used by the rest of the language. Something like
> the C# example linked before or the Tutorial D examples some
> have posted in c.d.t before. However, the "compiler" should
> ultimately include only the DBMS functionality needed to
> correctly implement the code rather than using a complete
> black-box DBMS server.
>
> For example, how much relational functionality could one
> incorporate into say a C++ library with relation classes, RA
> functions, etc without being a front-end for a full-blown
> DBMS back-end? Anyone know of any such libraries?

I am not current on the state of the art with C++. When I was, it lacked sufficient support for generics to create really effective relational operations. Physical independence is somewhat anathema to C++ in any case.

> Does it even make sense to talk about a relational language
> compiler that does not link to a full-blown DBMS?

Yes and no. Static compilation has been around for a very long time; however, the focus in those products is still files on disk somewhere.

I get the impression that most people think of database management as follows:

I have client computer over here where I run applications and it has no dbms.

I have a server or a distributed system of servers over there that have a dbms.

I don't look at it that way.

I think the dbms necessarily includes the client computers as part of the system. I further think that physical independence requires the ability to specify that some of the internal processing for the dbms will happen on the client computers.

For a simulation, one can usually reproduce the entire simulation from some (possibly large) set of initial boundary conditions. Thus, simulations deal with relvars that need never get stored on disk and for performance reasons ought to always stay in memory or be minimally shared among a cluster of parallel computers as needed to complete the task.

> I think I'm failing to describe such needs using correct
> relational and/or DBMS terminology. Am I making any sense?

Consider a dbms system like the one described above that supports static binary compilation and allows one to specify the logic of a simulation program that one can test locally on a client computer using fewer elements and then put into production on a cluster of networked computers just by recompiling with different instructions for the physical distribution of the work.

Nothing exists like that now, but that is exactly the sort of thing that physical independence means to me. The destination lies somewhere in that direction. Received on Fri Jun 23 2006 - 21:04:58 CDT