Different types of databases demand different containers, different tools, and different interfaces. Key factors to consider include:
- structure — Does the information fall naturally into neat rows and columns? Or is it disorganized and chaotic?
- immediacy — Are data items useful in their "raw" native form? Or do they need to be processed, massaged, and otherwise converted before they make sense?
- security — How much of a concern are privacy, data integrity, the presence of an audit trail, and other traceability issues?
- size — Does the information fit on a single sheet of paper, or a single spreadsheet, or a single machine? Or is it too large to be handled in a local system?
- questions — What are the problems that users will want to solve via the data? How do they vary in priority, in urgency, and in level of complexity?
- collaboration — Do multiple people need to work together with the information, either simultaneously or spread out over time? Can humans add value to the database by leaving footprints or adding annotations and commentary?
- extensibility — How many system requirements can be anticipated and designed in now? How many are by nature unforeseeable? How often will users need to do run-time scripting or programming in order to add new capabilities?
- transparency — Will researchers need to tunnel down from one part of the information space to other areas? Are hyperlinks or cross-references or other threading mechanisms needed?
- patterns — Are there questions which nobody knows how to ask, but which might be recognized by examining the entire information collection creatively enough? Are emergent issues implicit in the data?
These are the sorts of questions to ask when somebody says "I need a database!"
Wednesday, May 03, 2000 at 14:47:28 (EDT) = 2000-05-03
(correlates: IdeaGardening, NeatsAndMessies, Comments on Nobel Neutrinos, ...)