[REBOL] Re: REBOL Relational Object-oriented Database Ver. 0.4
From: gjones05:mail:orion at: 27-Jun-2001 8:45
From: "Dr. Louis A. Turk"
...
> Below is version 0.4 of the database. Some of my code may be rather crude,
> since I am still learning this language, but the code written by the other
> contributors looks great (to me at least). Unless there are some bugs I
> missed, the program works fine. It is not relational yet, but since it
> will be by version 1.0 (I hope) I'm leaving relational in the name to keep
> myself motivated to finish it.
>
> PLANNED IMPROVEMENTS (calling all experts for help!):
>
> 1. An edit-data function that will display the current data in the field
> so that the arrow keys can be used to position the cursor to change just a
> letter or so---so that the entire field does not have to be retyped to
> correct typos. I hate unnecessary typing! I am hoping that there are
> secrets hidden somewhere in REBOL that will make this function easy to write.
>
> 2. Relate two or more databases together on key fields so that reports can
> be written using data from all the databases.
>
> 3. Compress (and encrypt, if possible) the data file as it is being backed
up.
> 4. Would there be any practical advantage to putting a View face on this
> program, other than looks? Would using a View interface slow down
performance?
...
Hi, Louis,
Numbers 1 and 4 are probably best answered together. To my knowledge there is
no pre-built way to edit text. Like the kbhit function, it should be "do-able",
but is it worth the effort when this type of functionality comes with /View at
no cost. I don't recall running across an example in the library, but asking in
a separately titled thread (like you did with kbhit and compress) may elicit a
better response. I suspect that /View eclipsed the development of more
sophisticated text-based editing components.
An additional advantage that a /View version would offer is more flexibility in
laying out the relationship between the key field and data and access to any
field for editing without having to drill down to each field each time. As far
as performance, of course, there is a bit more overhead, but I have found /View
to be sufficiently efficient to satisfactorily handle data display in fairly
complex data structures.
If you have not used the /View VID, I suspect that you could feel very
comfortable using it after just a day or two of immersion. Your db has a very
snappy feel as is, so I personally would not feel compelled to convert if it
accomplishes what you wish for it to accomplish.
Number 3 has been addressed in a separate thread.
I remain a bit puzzled about number 2, and maybe it is only do to
mis-communication. The beauty of the system that Carl S. prototyped for you is
that the data object is nearly infinitely expandable to encompass any
combination of data fields that you might conceive of. Only one data "table" is
needed. The relationship is inherent in the object concept. While it is
certainly "do-able" to create a separate table that shares the key with the
initial table, I am unclear whether there would be any advantage to this
approach, especially for the small scale database that you have envisioned. Can
you give a hypothetical example of the kind of additional data that you might
wish to store? Maybe with a concrete example, I could at least prototype a
method to demonstrate the idea.
Regards,
--Scott Jones
