OT: What makes a DBMS multi-valued
Fairlight
fairlite at fairlite.com
Wed Mar 1 01:43:34 PST 2006
In the relative spacial/temporal region of
Tue, Feb 28, 2006 at 08:22:08PM -0500, Walter Vaughan achieved the spontaneous
generation of the following:
>
> [make sure you are reading this with fixed width fonts]
Always do. :)
> Remember all of that data is stored in a single record, and you can
> add as many multiple values and subvalues as you need. There are no
> record pointers, so fields can expand and contract as wide as needed, and
> indexes don't care.
Looks quite interesting. I've done something like this outside database
contexts, where you might be passing an array, but entries in the array
might actually be another array, or a hash. It looks like a very similar
concept but applied to actual storage.
> What even more interesting is that the procedure language is stored as
> records as well in the database, it is quite easy to write self modifying
> code if you want. And since the first applications of this were in
> Military and Government contractors, security is scalable from weak to
> particular fields in particular records with regards to read/write access
> by user/group/etc...
Definitely sounds interesting. Powerful, as well. But as with powerful
guns, you really want the person behind them to be well-trained. :)
> unless you know it already, or plunk down thousands of dollars for a
> class, the chances of you learning it today are slim and none.
It looks rather unwieldly to learn. Like I said, from the examples I've
done something similar in memory, but for a storage-based-solution I can
see this as probably being done with level separators. Say a record
separator is \000, a field separator is \001, and a value separator is \002
or something like that. You could just look for the separators. But I'm
looking at it from the standpoint of other things in which I've programmed.
I'm guessing they came up with language elements to specifically access
each part of a record, no matter how it's actually stored? You know, ways
to identify if multiple values are present and how many there are.
Boy, that's a real mind-blower when you take it to the point where six
out of ten fields could be MV. Just thinking about several individual
records varying wildly, there's no uniform data structure. Somehow I think
normalised is easier.
Sounds interesting though, and makes a LOT more sense to me than what I
read last night. Thanks for taking the time and effort to edumacate me!
mark->
More information about the Filepro-list
mailing list