CPAN: RFC on Schema (working-name: Swalow)

[Aahz Maruch]

In article <mailman.983270711.22031.python-list at python.org>,
Sean Reifschneider  <jafo at tummy.com> wrote:
>
>I started using the schema I posted last night, and through that ran into
>some changes that need to be made.  I'm not happy with the dependencies
>table, but that'll come along shortly.  At the moment, you can review
>the schema at:
>
>	ftp://ftp.tummy.com/pub/tummy/swalow/swalow-1.00/schema

It's a decent start, but I have a lot of suggestions (in no particular
order; I'm writing this as I go back-and-forth over the schema):

There's currently little support for archival information; you're going
to have to change a lot of the subsidiary tables to key on both
packages.itemID and packages.version (which could be packages.id, I
suppose; I flip-flop between pure normalization and useful denormalized
forms).

I think it might be a good idea to split items and packages into items,
versions, and packages, allowing multiple packages per version.  If you
do create the versions table, it should have an URL field in addition to
the one in items.  If you create the versions table, my comment above
applies to versions instead of packages.

I think the dependencies table should have fields for minVersion and
maxVersion, which apply to requiresItemID.  This is probably going to
require having a defined format for versions in order to parse them.  It
should be permitted to leave either or both of minVersion and maxVersion
blank.

I don't know what capabilities postGreSQL has, but if you can, I
strongly recommend adding foreign key restrictions on the subsidiary
tables (e.g. require that packages.itemID exist in items.id).
Similarly, you should put a unique index on items.name to prevent
inserting the same name twice (and in other equivalent spots, such as
packages.itemID/packages.version).

I think there should be an items.created datetime field, in case an item
gets created before there's a package ready for it.  I also think there
should be a packages.lastUpdated, which would be used if there was a
mistake in the packaging, but not the actual code that makes up the
package.

It's not really clear to me how you intend the relationship between
items, users, and maintainers to work, so I'll reserve comments on that
for now.

It's not clear to me what packages.architecture is for.

I have zero clue what ranking is for.

One final comment: you should probably change "All Rights Reserved" to
some kind of standard license -- GNU, BSD, whatever.
-- 
                      --- Aahz (Copyright 2001 by aahz at pobox.com)

Androgynous poly kinky vanilla queer het    <*>     http://www.rahul.net/aahz/
Hugs and backrubs -- I break Rule 6

Nostalgia just ain't what it used to be