1.1.7. Structure

Database structure

Fields should all have variable length, or in any case be 'very' hospitable: we are mainly dealing with text strings whose length cannot be predicted once for all: to allow up to 40 characters for the Publisher field is nonsense, we simply do not know in advance, we need free space.

At least some of the fields should be able to host multiple values with no practical limitation: multiple authors, multiple keywords (i.e. subject headings). Those multiple entities are not simply words: "water pollution" is one keyword. Multiple values have to be recognized and handled as such when building lists, indexes, sort sequences.

Are you looking for flexibility in order to add reference types and fields, and term lists?

Would you like to be able to modify fields attributes?

There exist products which work with a given, unmodifiable, number of reference types and fields (often including a few empty and neutral User-Custom fields), others let you add new ones: the utility of this difference is deeply appreciated when you manage your own project with specific requirements (e.g. dealing with a special collection, a very detailed bibliographic project with lots of fussy fields...).

As far as import filters and output styles are concerned there is no question, any product -I dare say- will allow you to modify the existing ones and create others.

Do you need to establish vertical and/or horizontal links between records, entries, records and notes etc.? Most of the packages we are dealing with do not offer this capability (the dead Papyrus was a remarkable exception), apart from the connection between an entry (e.g. a name or a keyword) and the multiple records which contain it. By far, most BMS are flat file managers with no relational database structure displayed to the user. 
But there are also relational database and SQL tables based applications like Biblioscape, Bookends and RefWorks, which are reviewed here.

Subfields is another prominent way to structure data: normally they are lacking in BFS database structure. The only exceptions are: name fields (author, editor, secondary author etc.  where one single comma marks the splitting into subfields) and the date field (publication year, where often the software can extract the year portion from a full date).


Table of contents  | Index