Re: RDMS Database's and/or Record Managers What good is Euphoria?
--Message-Boundary-8259
Content-description: Mail message body
On 23 Jan 2004, at 10:55, Isaac Raway wrote:
<snip>
> Don't get mean. I was trying to be clear.
Because you assumed i did not know what you meant? My original question
was about the function of munging a record already found by the file system,
and i am strangely unable to convey that to you. I know about database
access to drive contents, i know about various db index methods. Attached
is a file for seeking in 80x86 asm for Turbo Pascal that i used in the early
1990's to do database manipulation of drive contents. TP at that time did not
have byte seek methods of .txt-type files. Strtok.e is not about doing
whatever access method you wish for your database, since the hard/softdrive
random access overhead in many cases is too excessive for me, altho drives
are now much faster than the early 90's. I used a dynamic and
reconfigureable ramdrive in xms back then, which i could delink out of the
device driver chain to free up memory. Nowadays, ram is much cheaper.
What i was striving for, and asked about, was accessing items you already
located in the database and loaded into memory. But i am repeating myself
again.
And an editorial, ymmv, on hd byte pointers in modern OSs and modern
hardware: I have more than 4 ide devices on this puter, so i have a pci slot
ide controller. So with a drive on that card, the drive caches 8megabytes
(more than my total system ram back in the early 90's), the controller card
caches, the OS caches, the Eu interpreter caches, and then i hold a copy of
some of the data in my app. And the bios is prolly caching a little
somewhere, even if only temporarily. So the motherbd cpu is handling that
data many times before you see it, and the drive controller, the ide controller
card, and the dma chipset is playing in the data before your app gets it.
Trying to specify byte level control on the drive is an illusion, the days of
specifying the platter/sector/byte anymore is long gone, especially when the
OS is virtualising everything. Unless you are using non-multitasking OS and
doing bios calls, or no OS at all, and/or non-cacheing non-ide non-nrz pre-
mfm drive controllers, you don't have any byte control of those platters in real
time. Later this year, when 15k rpm 2inch harddrives come as pre-packaged
1/2 terabyte RAID clusters in a 5.25 form factor in ordinary desktops, byte
level control will be pushed even further away. The solution, is whatever
programming language you prefer, is Jiri's associated lists (or whatever you
want to call it), index the hell out of as much as you can, and buy as much
ram as possible for storage (or pre-storage: cache the start of the file in ram
so you can read it while the drive is looking for the remainder of the file, but
try doing that in modern OSs and caching drives, i dare you!).
Kat
--Message-Boundary-8259
Content-type: text/plain; charset=US-ASCII
Content-disposition: inline
Content-description: Attachment information.
The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any another MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.
---- File information -----------
File: MYDOS.PAS
Date: 8 Dec 1996, 4:34
Size: 1585 bytes.
Type: Program-source
--Message-Boundary-8259
Content-type: Application/Octet-stream; name="MYDOS.PAS"; type=Program-source
Content-disposition: attachment; filename="MYDOS.PAS"
|
Not Categorized, Please Help
|
|
