Reigning in Complexity

As mentioned in the Core Ideas section, a first step in dealing with the varied archaeological record and reigning in the application's complexity was to center its design around the module. This naturally lead to the use of relational databases with each module represented by a specific table (stones, ceramics, etc...).

As for accommodating different registration systems, while a generic solution is possible, we deem that a per module table(s) and accompanying code is a more realistic solution.

A few techniques were applied to allow for some flexability with regard to the variability of the records:

• free text fields such as "description" and "notes" columns are widely applied as catch all entries
• generic numeric "count" column used as a catch all entry
• when possible, properties were divided into seperate groups each containing a limited number of options.
• the trio structure (see Terminology and Core Ideas) with its dependency system were divised in order to link optional partition group options to the main module table via pivot tables