[Info-vax] OpenVMS - DCL - Data entry filtering

[Jan-Erik Soderholm]

David Froble skrev den 2015-03-30 21:15:
> JF Mezei wrote:
>> On 15-03-30 10:12, Stephen Hoffman wrote:
>>
>>> data and accessors and logging and the rest.   You blow past what RMS
>>> can do.   You might well reach the absurdity of directly rummaging
>>> SYSUAF.DAT, as I and others have implemented.
>>
>> ALL-IN-1 provided interface to SYSUAF which was field based, independent
>> of actual layout. DCL didn't. So people rummaged because of lack of API
>> that could have provided field level access to those files. (and then
>> allowed those files to change).
>>
>> Here is a question which has always bothered me. Database systems have
>> very opaque storage and indexing. (to me at least). Heck, I don't even
>> know which actual files store the data, index and what not.
>>
>> But if one were to compare RMS with the low level database storage in
>> file(s), would the indexing and buckets etc of RMS end up competitive
>> with how databases organise the data and do record searches/lookups ?
>>
>> MySQL seems to have a default file organisation that appears sequential
>> to me. ( so I use a different one which has indexed records where you
>> specify key fields, mostly because this is what I am familiar with)
>>
>> Seems to me tha a sequeintial file organsiation can't be all that
>> efficient when doing database lookups by a name, or record number etc.
>> It is fine when most of your lookups are wildcard searches. But not so
>> much when doing simple loomup by a key such as employee number.
>>
>>
>>
>
> Pull the entire database into memory, and you might be surprised how speedy
> it might be ....

You don't have to "pull" anything. Just let the database maintain the
buffer cache itself. If sized right you will get a high high hitrate.

>
> I don't know much about the internals of any of the RDBMS products. I've
> used Microsoft SQL-2000.  In the database tables, relationships could be
> defined.

Are you talkning about RI? "Do not enter this order if the article
number is not in the article table"?

 From what you write below it sounds as you are talkning about
normal indexes.

> I'm guessing (really guessing here) that they are similar to keys.

A "key" is usualy the same as an index. A "foreign key", maybe.
That is a rellationship between different tables.


> It's my guess that when you attempt to access data using one or more of the
> relationships, the access is less work and quicker.

That sounds more like normal indexes. They help with accessing
the data, yes. They also help whith RI.

> The more relationships, (more keys), the more work to add records (they
> call them rows) is my guess.

Yes, in general. But usualy faster and less work then doing the
same thing in your own application code. *And* (a *very* important
"and"!) the database maintains the RI no matter how it is accessed.

You can write whatever application code you like to maintain the
integrity of the data, if that breaks anyway by someone doing
interactive SQL updates or something through ODBC. By having
the RI defined in the database itself, the integrity of the
data is always maintained no matter how it is accessed.


>
> With today's HW and memory, the damn things appear to be very fast.