Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!cimshop!davidm From: cimshop!davidm@uunet.UU.NET (David S. Masterson) Newsgroups: comp.databases Subject: Re: Variable length records Message-ID: Date: 8 Jan 91 19:58:14 GMT References: <9385@latcs1.oz.au> Sender: davidm@cimshop.UUCP Distribution: comp Organization: Consilium Inc., Mountain View, California Lines: 37 In-reply-to: ang@latcs1.oz.au's message of 7 Jan 91 10:22:15 GMT X-Posting-Software: GNUS 3.12 [ NNTP-based News Reader for GNU Emacs ] >>>>> 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!"