Re: LDAP, DNS, & M-cards
Date: Sun, 18 Apr 2004 22:01:51 +0200
Message-ID: <4082deaf$0$568$e4fe514c_at_news.xs4all.nl>
Dawn M. Wolthuis wrote:
> mAsterdam wrote:
>>Dawn M. Wolthuis wrote: >>>...
> so, in theory, a DNS implementation could use a relational database?
Not just in theory, http://nickg.home.cern.ch/nickg/dns/sub_domains.pdf
>>>or if DNS has that "M-card design pattern" thing going. >>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,
I recognize it now, I think. Your somewhat anachronistic 'design pattern' put me on the wrong foot. Once upon a time there was a joke: "If you look at IBM harddisks closely, you can still see the punchcard-holes", but now even the joke is gone.
> given that an RDBMS would not allow this,
? It doesn't seem hard at all - but why would someone want that?
> 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.
Where punch-card-like constraints still govern, I guess. What did you have in mind?
>>>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?
http://www.tldp.org/HOWTO/DNS-HOWTO-5.html Received on Sun Apr 18 2004 - 22:01:51 CEST