Top Level Design

The AUGC instructor database needs to hold representations of the following types of data:

Instructors	We need to know about instructors for authentication purposes. Each instructor will have a username and password, other objects created in the database by an instructor will be marked as "owned" by that individual. Instructors will be able to edit objects they own.
Pilots	These objects have no explicit owner, and can be modified by anyone in the database. They contain the particulars of an individual trainee, including their name, an indication of their currency (perhaps... Instructors might not necessarily update that attribute, so we might choose to avoid storing incorrect values by not keeping it), status attributes to indicate whether the trainee has received an intro, a theory lecture, some practice, or a sign-off on various stages of training.
Comments	Comments can be attached to any object. Each comment has a name and date, an owner, and whatever text the creator has provided.
Ratings	Ratings can be attached to pilots. Each rating has a name, a date, and an owner (presumably the instructor who has granted the rating). Ratings will include such items as GFA and FAI badges and certificates, passenger authorizations, winch driver authorizations, cross-country ratings, AEI and instructor ratings. The database ensures that a pilot can only have one instance of each rating.
Conversions	Conversions can also be attached to pilots. Each conversion has a name, a date, and a type (glider). Conversions can be revoked and reinstated by instructors. The database ensures that a pilot can have only one instance of any given type conversion.
Types	Types are the things which define which conversions are allowed. The menu of types available for type conversions is populated by searching the DB for Type objects.
Templates	Templates record metadata about the other object types. The code which implements the API for the database doesn't have any built-in knowledge about the structure of any of the other object types, it instead queries the Template object applicable to whatever data it happens to be dealing with. Consequently, new object types can be added by creating new template objects, and many of the semantics of existing object types can be changed by editing the appropriate template. Template objects contain a list of attributes owned by the object class they're describing, some rudimentary type information for each attribute, an indication to distinguish mandatory attributes from optional ones, and an optional reference to a software module which should be executed whenever an object belonging to the described class is updated. Almost all of the software which manipulates objects is consequently able to be made generic, and the database is effectively self-describing.

The database assigns an object ID to each item of data, and enforces a heirarchy relationship between objects. Searches can be performed upon any attribute, or direct fetches can be achieved by requesting an individual object ID.

Where objects have owners, only the owner is permitted to perform modifications. Ownerless objects (Pilots and Ratings at present) can be modified by anyone.

The software will provide modules which understand how to display each object type as HTML (and, perhaps, PostScript for printing - or perhaps not, since web browsers can do PostScript conversions anyway). A further module will be provided to update objects. Attaching objects to each other will be accomplished by form submissions by end-users, which will cause the software to display an "empty" object ready for editing. Objects are never deleted from the database, although object attributes might be used to render a stored object irrelevent (e.g., when an instructor retires from the club, it'd be sensible for the instructors username and password to become invalid, but it wouldn't be reasonable for all objects owned by that instructor to suddenly become ownerless!)

The software very deliberately doesn't provide any indication of "currency". To expect an accurate report of currency would be to mandate that instructors must update the pilot's record in this database every time the pilot attends the airfield. We'd also end up with creeping inaccuracy when pilots flew with other clubs.

In leiu of currency, we will be able to record the date of the last checkflight -- Instructors can simply attach comments to the pilot. A facility to mark comments as "CHECKFLIGHT" reports will be provided in due course, and the most recent checkflight will be provided on a pilot summary report intended for the instructor's edification.

Every object in the database has a URL, which looks like http://augc.dotat.org/cgi-bin/db?tag=Object-ID. Object-ID is a six digit number followed by a letter, chosen by the database at object creation time to uniquely identify the object. The objectstore API used by the database knows how to retrieve an object when supplied with its object-ID, and how to obtain a list of object-IDs when provided with search criteria.