Re: Structuring attributed data-fields

OK. What would be your approach to incorporating the meta-data explicitly into the model? It seems to be that we need an entity that aggregates the attributes of interest i.e.

    A ManagedDatumAttributes consists of

• date/time when most recently updated;
• audience (public, staff, ops, ...). But then would I draw an association between this and *every* datum in the model? [If I do, then I can implement this by either the original "fat" table approach or the other original approach of having an attributes table containing primary-key fields that specify the field name and record key of the managed value datum].

Actually, the cleanest model I can think of is to take a template approach:

    A ManagedDatum<T> consists of

• a value of type T (accessed via a getValue()/setValue() pair)
• date/time when most recently updated (accessed via getTimeOfLastUpdate(), but changed only by the setValue() method).
• audience (public, staff, ops, ...). The rest of the model would then be defined in terms of the various bindings of this template e.g. A Flight has various attributes, including: departurePort: ManagedDatum<Port>, arrivalPort: ManagedDatum<Port>, etd: ManagedDatum<DateTime>, eta: ManagedDatum<DateTime>, status: ManagedDatum<FlightStatus> {FlightStatus in Set {boarding, locked-up, en-route, landed, ...} } [It seems to me that this approach would then map to having a table for each type T (with 4 fields: datum id, value:T, updateTime, audience), and the rest of the schema merely has foreign key refs to those tables' datum id fields].

I don't think inheritance-based or aggregation-based approaches to modelling these creatures is as clean as using a template.

• Angus Monro.