Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[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
> 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