DB schema

[ginny listman]

Thanks for your comments.  We've had some additional meetings here to
discuss some of the exact things you brought up...

On Thu, 4 Jan 2001, Shane Kerr wrote:

> All,
> 
> I've had a quick look over the proposed DB schema, and have the
> following comments/suggestions/questions:
> 
> o Please please please don't use HANDLE to represent the key for the
>   objects.  You should really think about using an internal identifier
>   as the key.  You can/should still make HANDLE a unique field, but
>   users use this to encode information (company name, network city
>   location, whatever), and as such want to change it.  This process is
>   much simplier with a distinct, internal-only, key.
> 
By this, I'm assuming that you would like to be able to change your
netname or as name.  If this is what you are asking, I would expect that
the Net/AS Name could NOT be changed via a template, but would have to be
a special request.  The only reason I would enforce this, is to avoid the
potential typo.  I believe the Net/AS Name is yours to change whenever you
feel it appropriate, but would like to have basic checks built into the
software.

> o Why isn't address stored in a seperate table like phone, mailbox, and
>   so on?
> 

We discussed the possibility of separating address, but in reality most of
the time we retrieve the individual/organization we also want the address.
One change that is not in the current conversion plan, but was discuss on
the list is the flexibility of multiple phones and mailboxes.  For this
reason, they will continue to be separate tables.

> o Can an organization or network have multiple parents?  If not, perhaps
>   it might make more sense to include a "parent" attribute in the tables
>   rather than use a seperate link table.

Good point, and will be incorporated.

> 
> o You'll need to add an "ordering" attribute to the tables, to allow for
>   stable sorting on the output.  For example, inaddr servers should
>   appear in the order the user specifies, and contacts should probably
>   also work this way.
> 
Another good point.  I didn't realize that order matter that much.  Adding
a sequence_no to the table should handle this issue.  As long as there are
no objections, it will be added.

> o Why use start and number of AS rather than start-end for AS
numbers? > 

Since this was Cathy's idea, Cathy do you want to answer this, or discuss
doing the start-end rather that number?

> o What's a "resource link"?

A resource is either a address space or AS.  This table has been
eliminated, and an org_handle be included in the neetwork and as_number
tables.

> 
> o What's a maintainer?  Please just kill this beast, or at least define
>   it in a meaningful way.  :(
> 
This is another one for Cathy to answer.

> o What are you going to do about the gazillion non-CIDR networks that
>   exist today?  There are a lot of networks in the ARIN database that
>   are (for example) a /24 and the subsequent /25.  I suggest that you
>   should store networks as start-end in the database, even if you remove
>   this from the templates and/or web forms.  On output, you can convert
>   to between 1 to 31 CIDR networks, but it's probably simplier to just
>   store start-end ranges when storing the addresses.
> 
Storing in cidr or range has been discussed in depth here at ARIN.  CIDR
has become the way of the world.  RSG works in CIDR.  If an allocation is
more than one cidr block, that's okay, it will be represented as multiple
cidr blocks.

> o Am I the only one who hates templates?  ;)
> 

In my research, I'd have to say, no...

> Shane
>