Re: [Q] DNS(bind) ER model
От | Roderick A. Anderson |
---|---|
Тема | Re: [Q] DNS(bind) ER model |
Дата | |
Msg-id | 48A86306.4070001@acm.org обсуждение исходный текст |
Ответ на | Re: [Q] DNS(bind) ER model (Mark <markdv.psql@asphyx.net>) |
Список | pgsql-general |
Mark wrote: > On Thu, 2008-08-14 at 16:20 -0700, Roderick A. Anderson wrote: >> Anyone aware of an ER model for holding name server records? >> >> Working on the zone file data and I am getting close but keep running >> into the differences between MX records (with a priority) and the others >> that can hold either a domain/sub-domain/host name or an IP address >> depending on whether is an A, TXT, PTR, etc. or a CNAME. > > Don't add a column for the prio of the MX record. A lot of designs do > this but IMHO it's crap. If you do it for MX records you also have to do > it for SRV records and who knows what other (future) records). I was working towards that direction. I really hated the idea of a sparse table and even a sparse column. > > We (@work) use an in house designed database that use the best technique > I've ever seen. > > What it does is use a table to list all the valid RR types(1) along with > an ID and regular expressions that describe what the name and rdata > should look like. Interesting idea. A project I worked on awhile ago did something similar. Actually stored some Perl code. > In the table that holds the dns records the type of the record is > foreign key referencing the type table. And insert/update triggers are > used to check that records match the patters in the types table. Better and better. > With this technique supporting a new record type is as easy as inserting > a new row in the types table. And it also garanties that all records in > the database is at least syntactically correct. (Assuming your patters > are correct of course.) Thanks, Rod -- >> Much of the database will be populated and changed automagically so the >> controller for the application will do the right thing but humans will >> get involved every so often. I hope I can get the database to make the >> right thing easy and the wrong thing "impossible" for them. >> >> Any suggestions? > > HTH. > > Cheers, > Mark. > >
В списке pgsql-general по дате отправления: