I use various concepts throughout these Help pages so this is a page to talk about those concepts.

  1. Databases

    The Garden Notebook application needs to store the data you enter so that you can look at it (and change it) later. The application stores all the data where you tell it to; the application never attempts to send your data to any external party nor to contact any external party.

    The mechanism the application uses to store your data is called a database, technically a Relational Database Manager or RDBMS. There are many RDBMSs on the market but this application can only work with a few of them, all of which are available free for personal use. The installation instructions (see the ‘Download‘ page of the website) describe how to set up these RDBMSs for use.

    The application comes with a bundled copy of hsqldb so that you can use it straight out of the box. You specify exactly where you wish this RDBMS to store your data. hsqldb holds its data as ordinary text files so you are free to move them around, copy them for back-up, etc, as you wish.

    It's worth mentioning how a database stores data. An RDBMS can be thought of as a sort of card index file with a drawer for each type of item and a card for each item; technically, these are called tables and rows. So here, for example, we have a Plant Species drawer and a Plant Variety drawer. Each plant species card has a unique index number (or id), the name of the species (tomato, aubergine, etc), a description and various other facts; of these, only the id cannot be changed. Each plant variety card is very similar, with a unique id, a name (moneymaker, ailsa craig, etc), description, etc. To say that this is a variety of a particular species the card also has the index number of that species; so we can have separate cards for the variety moneymaker for tomato and aubergine, say. By using the index number rather than the name of the species, we are free to change the name of a species without losing the relationship to its varieties. This is means that if you mistype a name when you first use it, it's easily corrected later.

  2. Catalogues

    The Garden Notebook application works with two sorts of data. One is the day-to-day Diary Entry which is what you are mostly interested in, the other is catalogue data. The catalogues hold the fixed information your diary entries depend on, such as plant species.

    Some of the catalogue data are pretty well fixed, such as the list of Husbandry types, although you can add, delete or rename any of these. Other catalogue data are quite dynamic, such as plant species or retailers. In all cases, when you need to use a catalogue data value the editor will present you with a drop down list; you can simply type a new value into the text area and that value will be added to the database for future use. This is particularly useful for plants.

  3. Diary Entry

    These are the day-to-day entries which record what you have done. Most entries will be of the Husbandry type, reflecting the life stages of a plant. Groundwork entries describing the maintenance aspects of gardening (digging, erecting bean poles, etc) can also be made as well as the inevitable problems of pests and diseases. Purchases and Sales are also diary entries.

  4. Editors

    To add an entry to the database you need to use an Editor. The various ‘Add’ and ‘Change’ buttons and context menu entries will bring up an editor of the appropriate type in a new tab on the Main Page. These mostly follow the same pattern (Purchase and Sale editors are more complex). There is a date for the new entry (initially ‘today’ but changeable), text fields to enter values specific to the sort of entry and a table to add or change comments.

    For many entries the specific values will be all that's needed, for others the comments carry most of the value - I use the comments a lot on Husbandry entries but hardly at all on Purchases.

    As I've said before, you can add new values for catalogue items (such as plants) in the drop down lists on the diary entry editors. Note that you can only add new values, not change the spelling of an existing value; to change an existing value, go to the appropriate catalogue and use the editor from there.

  5. Purchases

    In concept a Purchase is a straightforward record of something you bought that you think is worth recording. My motivation was to be able to see how much compost, say, I'd bought last year so that I could get ahead of the game this year and not have to make an emergency run to the Garden Centre (I still run out…). There is no intention of any sort of book-keeping functionality, just what you might write down in a paper diary.

    But it all got a bit out of hand. Obviously, you buy things from a Retailer and it's nice to have the Retailer in the database exactly once so that you can check purchases against retailer and avoid slight spelling differences.

    When I buy seeds mail order I buy lots of different ones, so I need a ‘purchase’ to have a number of purchase items or purchase lines, and I can use each of those as the start of a History Tree.

    To keep the seeds sensible I needed to add the concept of product - you buy a product which can be identified on the database and linked to purchase items.

    To check how much compost I bought, I need to have ‘compost’ as a specific type or category of product. This also meant I could distinguish plant type products named for plant species and varieties from, say, compost.

    All this makes the Purchase editor rather more complex (and powerful) than you might expect. In practice, it means that after you've added in any extra products you buy, most purchases can be recorded by simply dragging and dropping or selecting things from lists with very little typing. And the search features are quite powerful.

  6. History and Trees

    One of the most useful features of the Garden Notebook application is the ability easily to link various entries into a ‘history’ or ‘story line’, in much the same way as conversations get ‘threaded’ in email or social media. For example, starting with the purchase item for some seed, you can easily link the various sowings of that seed back to the purchase and for each sowing link the entries for germination, pricking out, planting out, harvesting, etc. This gives a sort of branching structure rooted at the purchase; this structure is common in computing and is called a tree. (For the technically minded, it's a directed, acyclic graph.)

    There are various bits of jargon associated with trees which I sometimes use in these help pages. Each entry in a tree is technically known as a node, the immediate children are sometimes called daughter nodes and the immediate parent a mother node. The collection of later nodes (daughters, granddaughters, etc) are the descendants; the mother, grandmother, etc are the ancestors. The descendants of any given node are a sub-tree. A node with no daughter is called a leaf. The earliest ancestor in a tree is the root. In this application, a node may have no more than one parent but may have any number of daughters.