1. Re: RDMS Database's and/or Record Managers What good is Euphoria?
Kat wrote:
>>Well, I've never used strtok, but I will give it a try now that you
>>mention it. It looks to be most useful for parsing source code (which is
>>great), but not for creating a database. Databases should not be doing
>>any string tokenization of any kind. That wouldn't be a database, it'd
>>be a flat text file.
>>
>>
>Strtok was written to do data handling as far away from strict Pascal and C
>records as possible. Been there, done that, not again.
>
>
I didn't say anything about Pascal or C records. I'm talking about
records in a relational database table, or a more flexible system in a
object persistence system.
>> Databases use virtual file systems with paged
>>storage methods and separate indexes, and most importantly, always
>>access their data files in a binary fashion.
>>
>>
>Not always. I found most of my accesses are wildmatches. Can't do a btree
>with wildcards. And as for "relational", Tiggr's has pointers to other data
>items, executeable code, etc. And the db is not stored in memory. And the
>
>
I didn't mean memory by paged storage methods. I mean that the
database's actual disk file uses it's own pages, or sectors, to store
the data. So, it allocated pages when needed, and markers them as
deleted to be reused just like a physical hard drive. For seriously
large databases with variable sized records, this is the only practical
way to handle the data.
>contents are not fixed in any way or form.
>
For a business application, that could be a bad thing, though personally
I do like flexibility to add fields to records, etc.
>If i turn her lose, there is no way
>the 5 gigs of data can be put in a Eu sequence in memory,, i'd need 20gig to
>load it, and another 40gig to manipulate it, and i don't have the money to
>waste like that. How you store and access the data on the drive is not
>strtok's business.
>
>
It should be, because serious databases have most of their data on the
HDD most of the time.
>But recently, someone asked about the access speed for a 1meg file, i gave
>code to read it in one sec, and parse the lines out in 1-2 sec (233mhz cpu),
>as if each line was a data item. Each line could have held separate fields,
>free form lengths, and each of those could have held more fields, etc etc.
>
>
Most SQLs read from multimegabyte files much faster than that. If you
can count access time in seconds, you're in trouble.
Through all of this discussion, please keep in mind that I am talking
about truly massive databases. At least thousands of records.
>
>YMMV
>
>
Forgive me, I don't understand this... ?
~ Isaac
