It was not my intention to explain all details of database design. If you take
a look at my message again, part about contacts, you'll see that model
mentioned there encompass what you have described (if I described well, for
which I give no warranty :).
Firstly, let's make it clear, your domains that have the same data will not
have several copies of contact handles (if they are in the same profile, and
you used bulk registry, or any existing domain as template). If you create
domain, as one off, well yes, we will not look in database to try and match
with some existing data - that case you have separate contact handle.
Now, as long as you have the same contact info for all domains across the
profile, database will store only one copy of customer data. Problem begins
when you decide to update only ONE contact, for ONE domain (or any non full
subset of contacts). In this case. we will 'split' contact into two, i.e.
create another contact handle and attach it to 'requesting domain'. The rest
of domains will point to previous contact handle. This is no rocket science,
it's very basic m:n relationship, and I did not feel that I have to explain
it, nor implementation.
The only difference to NSI system(Registrar) as you described it, is that you,
yourself with OpenSRS have no direct control over contact objects. Contact
manipulation is done for you in the background, by our interfaces. Hence, I
said we have contact handles, but they are not exposed.
And it might be good idea to give you control over this object, but I'm not
completely sold on it. Reason is that we are trying to hide for you complexity
of working with all different registrars. Tucows supports
.com.,.net,.org,.cc,.vc.,.tv. ,.ca,.info,.biz, and you can have all of these
in the same profile! It possibly makes it a bit easier for us, if we are in
full control of contacts. Haven't given too much thought to this subject, I
personally was not too much aware of customer's needs - just trying to get to
speed on that one.
regards,
Z.
cpaul wrote:
> Chris Paul wrote:
>
> > > > finally, is there a logical explanation for why opensrs doesn't have
> > > > contact handles?
>
> Zeljko wrote:
>
> > > Not sure what exactly are you referring here.
> > >
>
> Kai Schaetzl wrote:
>
> > What he means is that there are objects in the database: handle objects
> > and domain objects, they are all independant from each other. A domain
> > object is usually associated with 1 - 3 handle objects. If you update
> > ONE handle you have "virtually" updated ALL associated domains. This is
> > the way NSI has always been handling this (ajd still doing so) and the
> > same way all European registries handle this. It makes managing domain
> > data much easier and possibly reduces the database size a lot.
>
> ummm... yeah :)
>
> i presumed this is a fundamental aspect of database design.
>
> store the one piece of data....... once.
>
> why do all my domains that have the same admin, tech and billing contacts,
> store this information all over the place? makes me wonder what else is
> going on inside that database of yours, guys :-)
>
> nsi solution (which i'm sure with which we're all very familiar) works
> really well, and enables this fundamentally important "normalisation" of
> the database. you register a contact... once... and then use a pointer
> (or handle) to that contact elsewhere.
>
> Zeljko, here is where one registers a contact handle with nsi:
>
> http://www.networksolutions.com/cgi-bin/makechanges/itts/handle
>
> and here's an example of where one might enter the contact handle:
>
> http://www.networksolutions.com/cgi-bin/makechanges/itts/host
>
> one can enter the handle, or enter a fresh contact. either way,
> one only enters the contact into the database once. next time
> around, you use the handle (or contactID) .... because most of
> us, i am sure, are loathe to enter the same data again and again
> when it's been entered previously :-)
>
> for those managing several domains, it also makes moving house,
> office, or email address <cough>, a far less taxing experience.
>
> thanks
