Re: LDAP, DNS, & M-cards
Date: Sun, 18 Apr 2004 08:41:33 -0500
"mAsterdam" <mAsterdam_at_vrijdag.org> wrote in message
> Dawn M. Wolthuis wrote:
> > ... What I haven't been able to figure out is if the "record types" are
> > in separate tables (one table per type) ...
> AFAIK the DNS is a distributed hierarchical database
> implemented as a protocol.
> Any server or resolver complying to that protocol could be said to
> be part of the dbms. Any such program is free to choose whatever way to
> maintain it's part of the data, as long as it talks with the other
> programs in adherence to the protocol. BIND is such a program.
> What's that?
When a single "file" is used to store records with varying schema, it needs one template/schema from which one can determine which schema to apply to a particular record. This was done all of the time (and likely still is) with flat sequential or index sequential files, particularly with the input records into batch processing. It came from the "card deck" era. A file used for updating the database might have an "M" in the first column and the batch process would then look at this record as an "M card" in order to maintain a "master file" and then a "T" in the first column for a transaction. I don't know if there is any common terminology used today for such an approach, given that an RDBMS would not allow this, so I've referred to it as an "M-card" design pattern. It is not frequently warranted today, but there are times when this design scenario might be very useful.
> > Does anyone know how DNS handles these different record types or can you
> > point me to a good URL for more info that would describe the underlying
> > structures?
> Every participating program needs to have some underlying data stucture,
> of course - but they may all be different.
So, then I'm curious whether these "record types" are just part of parameter strings in all cases, or whether any implementations of DNS actually store records of varying "types" within the same file. I would rather refer to this data design pattern in a way that those a bit younger than I might be able to relate to. Thanks. --dawn Received on Sun Apr 18 2004 - 15:41:33 CEST