On Thu, 25 Oct 2012 03:56:39 +1100, Chris Angelico said:
> On Thu, Oct 25, 2012 at 2:42 AM, Steve Litt
> <slitt@troubleshooters.com> wrote:
> > Also, with the organization they're using, one can make new
> > "columns" on the fly. ... Anyway, the keypuncher is punching
> > data, comes across a brand new type of data (let's say "artist"), so
> > for this row the keypuncher puts in a key-value pair of "artist=Lady
> > Gaga". From a practical point of view, data structure could be
> > change at key entry time, and needn't have been anticipated by the
> > programmer nor recompiled or reorganized when a new type of data
> > element entered the requirements.
>
> That's wonderfully flexible, but it forfeits the protection that a
> well-designed schema gives. A system like that is likely to end up
> with different records storing the same data under slightly different
> names, and you'll have a massive proliferation of "columns" that have
> only a single row's value in them. That's fine if that's what you
> want, but from a data entry standpoint, I think it's _too_ flexible
> for most purposes.
True enough.
In my particular case, my program was used by litigation support
professionals (I probably shouldn't have called them "keypunchers") who
knew what they were doing. Secondly, IIRC, I had a separate table for
field names, so that before creating a new field name, they'd be
presented with the current ones.
One possible way of limiting the possible damage you pointed out would
be to have only a select few be permitted to add new field names. I
think my program might have done that -- I seem to remember those
entering data having to call the supervisor to put in a new category of
information.
But yeah, the data organization I mentioned requires use by halfway
intelligent and competent users, and certainly isn't universally
appropriate.
Thanks
SteveT
Steve Litt * http://www.troubleshooters.com/
* http://twitter.com/stevelitt
Troubleshooting Training * Human Performance
