Re: LDAP, DNS, & M-cards

"Christopher Browne" <cbbrowne_at_acm.org> wrote in message news:c5v603$66o41$1_at_ID-125932.news.uni-berlin.de...
> In an attempt to throw the authorities off his trail, "Dawn M. Wolthuis"
<dwolt_at_tincat-group.com> transmitted:
> > "mAsterdam" <mAsterdam_at_vrijdag.org> wrote in message
> > news:4081f386$0$568$e4fe514c_at_news.xs4all.nl...
> >> Dawn M. Wolthuis wrote:
<snip>
> > 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.
>
> That would presumably be a _process_ question, as opposed to a
> _database_ question.
>
It is more of a super and sub-type question. I am not promoting this approach to database design, but historically there have been many designs that have a super type (such as "transaction card deck" to show the historical nature of my question) and multiple subtypes. The supertype may have n attributes that are common among all sub-types, but then each sub-type effectively defines the remainder of the record differently, according to what fields are required for its sub-type.

> BIND 'zone files' do contain numerous sorts of records; this enforces
> between zero and nothing on how one would use a database system to
> store the data.
>
> But it seems pretty usual for "Pickies" to conflate those things,
> which makes it rather more difficult to "pin down" either process or
> storage.

I'll believe you on that, but if you have an example, that would be helpful.

> >> > 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
> > data
> >> > 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
>
> Look for any BIND "HOWTO," and you'll presumably see that the
> serialized form of a zone file does indeed store many different
> "types" of records in a single file.

Great! I'll check it out. Just so you understand -- I'm not promoting this approach for most situations, but I appreciate having a more current example of this approach because it was so widely used.

> This of course imposes _nothing_ on the implementation of a DNS
> server, which may use any sorts of data structures the implementor
> wishes to use.

Got it -- thanks! --dawn Received on Mon Apr 19 2004 - 02:47:19 CEST