ang@latcs1.oz.au (Ang Cheng Chai) (01/07/91)
Hi there....
Would it be too brash of me to request for pointers to literature
as to the options one has when trying to implement a variable length
records DB?
I am trying to cater for a situation where the data structure of
the records frequently get modified and am trying to avoid having to
reorganize the database.
Many thanks in advance,
Chai.ubiquity@cs.utexas.edu (Richard Hoffman) (01/07/91)
In article <9385@latcs1.oz.au> ang@latcs1.lat.oz.au (Ang Cheng Chai) writes: > Would it be too brash of me to request for pointers to literature >as to the options one has when trying to implement a variable length >records DB? You might want to start with Knuth, Vol. I (Fundamental Algorithms). It contains a lot of basic work in space management, some of which is still "state-of-the-art". Particularly, you might be interested in "Buddy Spaces". -- Richard Hoffman IBM Entry Systems Division (512) 823-1822 1529 Ben Crenshaw Way Austin, TX 78746 "Life is a gamble at terrible odds; (512) 327-9232 if it were a bet you wouldn't take it" (Tom Stoppard)
ghm@ccadfa.adfa.oz.au (Geoff Miller) (01/08/91)
ang@latcs1.oz.au (Ang Cheng Chai) writes: >Hi there.... > Would it be too brash of me to request for pointers to literature >as to the options one has when trying to implement a variable length >records DB? > I am trying to cater for a situation where the data structure of >the records frequently get modified and am trying to avoid having to >reorganize the database. Are you planning to write the DBMS yourself or set up a database using a commercial DBMS? If the latter, Pick or its clones (UniVerse, Prime Information) will do the job very well - in fact, that is the type of application for which they are ideal. If the former, you might still find it useful to read some of the literature on Pick to see how it handles this problem. Geoff Miller (ghm@cc.adfa.oz.au) Computer Centre, Australian Defence Force Academy
mpledger@cti1.UUCP (Mark Pledger) (01/08/91)
ang@latcs1.oz.au (Ang Cheng Chai) writes: >Hi there.... > Would it be too brash of me to request for pointers to literature >as to the options one has when trying to implement a variable length >records DB? > I am trying to cater for a situation where the data structure of >the records frequently get modified and am trying to avoid having to >reorganize the database. Check out an excellent book on file structures called: FILE STRUCTURES: A Conceptual Toolkit, by Folk & Zoellick It has C and Pascal algorithm for different file structures. One of these file structures is of course variable length fields/records. Hope it helps. -- Sincerely, Mark Pledger -------------------------------------------------------------------------- CTI | (703) 685-5434 [voice] 2121 Crystal Drive | (703) 685-7022 [fax] Suite 103 | Arlington, VA 22202 | mpledger@cti.com --------------------------------------------------------------------------
davidm@uunet.UU.NET (David S. Masterson) (01/09/91)
>>>>> On 7 Jan 91 10:22:15 GMT, ang@latcs1.oz.au (Ang Cheng Chai) said:
Ang> Would it be too brash of me to request for pointers to literature as to
Ang> the options one has when trying to implement a variable length records
Ang> DB?
I think you need to define more of what you mean by variable length records.
Do you mean a text database?
Ang> I am trying to cater for a situation where the data structure of the
Ang> records frequently get modified and am trying to avoid having to
Ang> reorganize the database.
There is always going to be a trade-off between what you call data and what
you call metadata. When a database is reorganized (in the way that you mean),
its the metadata that is changing. To avoid this reorganization, you need to
push more of what you would normally think of as metadata into data. As a for
instance, look at the data dictionary that most relational databases have.
Every relational database is composed of tables, tuples, attributes, etc. and
that is the data that the data dictionary records. Since most relational
databases do not allow for changing the conceptual nature of a relational DB,
this data dictionary information remains fixed in structure. This is the type
of concepts that you must look for in your application.
Obviously, though, there is performance overhead in constantly translating
data into metadata for other parts of the application to use (just as the
relational DB must translate records from the ATTRIBUTES relation into
information that can be used in the query of a table). Once your application
stables on a structure, though, you can begin moving back to the normal way of
developing the database.
--
====================================================================
David Masterson Consilium, Inc.
(415) 691-6311 640 Clyde Ct.
uunet!cimshop!davidm Mtn. View, CA 94043
====================================================================
"If someone thinks they know what I said, then I didn't say it!"