About twenty years ago, I tried to commercially develop database applications for the social sciences and humanities. At that time, very, but very few researchers in those fields were interested. Times have changed.
However, most researchers do not use nor even understand the use of relational databases. I still feel that is a big loss for these fields. So, I have started writing some stuff down to bring some light, particularly to the historical disciplines. It is rather fragmented, but perhaps that will change in the near future.
After having worked in academic research for 15 years, I started working as a ‘research engineer’ at the department of Economic History at Lund University. About half of my time, I spend developing a relational database that contains data about Swedish innovations. You can find a short overview of the features of this database here, and the project website here.
Choice of software depends on data structure
Many researchers take the tools of their trade as a natural choice. However, there is nothing natural about even the simplest text editor. It’s also not that long ago that the average historian saw the point of using a computer. One of the arguments that should inform the choice of software comes from the data and the structure of the data that is necessary to answer a research question. On this page, I am presenting some examples and explain what I think should be the choice of software for each of them.
Your data hub
You’re likely to just start making your data with whatever software seems ‘natural’ to you. However, hold on for a moment, and consider the near future of your research project. Your table, notebook, network graph, or what have you, may quickly turn into a data hub. Continue reading here.
Book review: Michael J. Hernandez ‘Database design for mere mortals’
Many software manuals and help-functions are written in the format ‘If you want to do X, you need to click this button. If you want to do Y, you need to select option this-or-that’. This is why software manuals can be useless to beginners: they don’t explain why you would want to do X or Y. This book tells you all about that. It teaches you how to design a relational database, rather than how some database software package works. Read the review here.
Book review: Bella Martin and Bruce Hanington, ‘Universal methods of design’
If you are designing software, database systems, websites or other digital stuff, this book deserves your attention. The book describes ‘100 Ways to research complex problems, develop innovative ideas, and design effective solutions.’ as its subtitle claims. Organized alphabetically, each method receives two pages of attention. More tagging and indexing to make the book better accessible would be nice extras, but that does not take away that, as it is, it already is a good read and a treasure trove of design methods. Perhaps not all methods apply to your needs, wishes and circumstances as a designer, but those may change and as long as they don’t, I am sure there will be some interesting methods for you left worth exploring. Read the entire review here.
A universal date table
For historians the date field is a particularly important field. Considering how obvious this is, the support for dates in database, spreadsheet and other software is mediocre at best when it comes to historical data. The most important problems are : supported dates may not go back in time far enough, usually dates can only be entered in the Gregorian calendar (i.e. the currently standard Western calendar), mapping of different calendars is therefore also absent and (last and least in this case) the different formatting of dates is problematic. This page proposes a solution for these problems in the form of a universal dates table. Continue reading here.