[REBOL] Re: dbms3.r 01
From: rgaither:triad:rr at: 15-Jan-2002 8:55
Hi Pekr,
>Maybe the block structure is the way to go. If you look at current ODBC Rebol
>solution, it retrieves block of blocks (records), transformed or not, into Rebol
>datatypes. I already have several functions, where I can map such record to
>object - very comfort aproach, using foreach ....
I think a block structure is the way to go at the storage level. I think the
tools/driver will need to be objects. A result set could be returned as a block though.
>foreach record record-set [rec: map-2-object template record .... do something
>with that object ...]
>
>, where template can be retrieved as simply another query to datase (in case of
>ODBC "Insert odbc-port ['columns dbname]), or just predefined (then only fields
>available in template map ....)
Yes, this is a good relational point - the schema or template stored and operated
on in the same table/row/column structures.
>What I am more interested in is - data integrity. If we will use only one file for
>our db, do we have to save upon each change? Because if we don't do that, and our
>app crashes, all changes are lost ....
These issues exist for any number of files used. It is something to think about
for any of the format options.
>As for unique IDs, Elan took the right aproach imo. Rebol is about distribution,
>so don't start creating dumb system, if you really don't require only that, and
>nothing more. But I know the tastes - once you finish it, you will want to add
>another features. Elan for e.g. created system, where each video store could be
>assigned unique ID thru CGI process on some remote machine - ID unique to all
>video stores using the app.
I don't like the remote machine approach (ID server or service). I would prefer
something along the lines of namespaces and local ID management.
>Also - per-file-record was MUCH better aproach, than storing everything in one
>file, unless you open the file on disk and forget memory based aproach. What is a
>little bit of a problem is - you use file system, so performance can vary. But
>hey, you just wanted to handle some 100 - 10K records, no? Again - look at what
>Elan did, and improve upon it, IIRC he used some techniques, which could be
>improved ....
I will review what Elan did in his book but I don't remember being
comfortable with it the first time around. Again I think it had directory
requirements as well as too many files for my preferences.
>As for database normalisation - come on, guys ;-) You want to achieve some simple
>db functionality, yet considering db normalisation? We created some middle size
Guilty as charged. :-)
I want multi-user and transaction support as well...
>As for me, once open/seek mode is available, I would try to go with XBase format -
>many tools use it - FoxPro, Clipper, Visual Objects, Visual Basic, Delphi can,
>etc. etc. - there are already tools to browse such data, and I can provide you
>with format description. But, huh, too much of work and wheel reinvention in any
>case :-)
It is tempting but not what I am after. If we get to the binary version of
this effort that format will not be what I pick. Might as well use a DLL from
Delphi and work through it at that point.
>So, for me, even if done in Rebol, I can't think of anything simpler then what
>Elan created, although I don't like the idea of some tens of thousands of records
>scattered around my hd in form of small files :-)
That is the challenge of it isn't it! :-)
Thanks, Rod.
Rod Gaither
Oak Ridge, NC - USA
[rgaither--triad--rr--com]