Author Topic: Software for strays  (Read 1083 times)

Offline Mad01

  • RootsChat Extra
  • **
  • Posts: 24
  • Census information Crown Copyright, from www.nationalarchives.gov.uk
    • View Profile
Software for strays
« on: Sunday 09 May 21 18:17 BST (UK) »
Hello
I'm looking for a software package that can deal with strays, not the surname :) but the people who stray from their original area.

The software will have to deal with all the details, like names, dates, places and references.

Do I use a spreadsheet database? I am hoping to update the present database onto our FHS website as the present software is a bit out of date.

I would appreciate all the help I can get.

Offline andrewalston

  • RootsChat Aristocrat
  • ******
  • Posts: 2,932
  • My granddad
    • View Profile
Re: Software for strays
« Reply #1 on: Monday 10 May 21 15:14 BST (UK) »
So you are hoping to keep track of people who were, say, born in your town but then moved away?

I think that I'd stick with a spreadsheet for now. That would make it relatively simple to transfer to something else later, and can be searched easily in the meantime.

Stick to one line per original record. Don't try to have, say, 3 census records on one line, even if you are sure it is the same person. Spreadsheets can be sorted and filtered easily to reveal the connections.

That leaves the task of deciding what you need to keep on each line. Consider various types of record  and what you might like to look for when searching. You will want to include some method of locating the original record.
Looking at ALSTON in south Ribble area, ALSTEAD and DONBAVAND/DUNBABIN etc. everywhere, HOWCROFT and MARSH in Bolton and Westhoughton, PICKERING in the Whitehaven area.

Census information is Crown Copyright. See www.nationalarchives.gov.uk for details.

Offline Mad01

  • RootsChat Extra
  • **
  • Posts: 24
  • Census information Crown Copyright, from www.nationalarchives.gov.uk
    • View Profile
Re: Software for strays
« Reply #2 on: Monday 10 May 21 16:16 BST (UK) »
Thank you for your input. I have started to collect strays and some are MI. My question is about the content of the inscription.

If I give each entry one line, I can then place a link with each entry to a database that will give extra information.

I will start with the spreadsheet as that makes sense. The database will come later.

Thank you again, nothing better than a plan.

Offline Nick_Ips

  • RootsChat Veteran
  • *****
  • Posts: 541
  • Census information Crown Copyright, from www.nationalarchives.gov.uk
    • View Profile
Re: Software for strays
« Reply #3 on: Thursday 13 May 21 11:11 BST (UK) »
Thank you for your input. I have started to collect strays and some are MI. My question is about the content of the inscription.

If I give each entry one line, I can then place a link with each entry to a database that will give extra information.

This sounds like the problem I had when I started out with my research, and it sounds like you've arrived at the same answer.

I decided not to rely on third party software or online systems and instead keep the bulk of my information in spreadsheets and databases - mainly because I had lots of information (photos, newspaper clippings, mourning cards, address books etc) and didn't know who all the people were and whether they were family or friends.

I created a table for each type of record, with one line per person mentioned - so for example a newspaper clipping which refers to three people would have three records.

The same applies to MI's I've found - each person mentioned in the inscription gets an individual record containing names, dates, relationship etc.


The key to making it all work is to use unique reference numbers for each person and each item. The reference number doesn't mean anything in itself, but does allow cross-referencing between the different bits of data.

Doing this, the structure you end up with is effectively a Relational Database.

So if your first piece of information is a MI for John Smith buried in Colchester then I would add a record to the 'People' table for John Smith and give him the unique personal number '1'. In the table for MI's I would add a record with it's own unique reference number and put in the information from the MI, and have a column in which John Smith's unique personal number is added to show that MI is related to the known individual.

The advantage of this approach is that later on you would be able to query all of the data to find any records relating to person '1' - the John Smith of interest - rather than querying "John Smith" and having to sort through lots of unrelated records.

It also means you can add speculative or unrelated data. For example if John Smith's MI says "much missed by his friend Tom Jones" you can add a record in the MI's table (using the same unique MI reference number), but without having to add him to the 'people' table. If you later find a connection to Tom Jones it is then a simple job to add him to the 'people' table and then enter his unique reference on the MI record.

I've probably made that sound more complicated than it is, it is hard to describe without diagrams showing the structure and links between the data. But it sounds like you are already on the right track.

I will start with the spreadsheet as that makes sense. The database will come later.

Spreadsheet tables will be fine, but the only thing I would say is that if you intend to move to a database later then it is likely to be easier all round to start with the database.

Database software will allow you to import information from spreadsheets, but it can be tricky to establish and maintain the links between different sets of data.

A relational database like Access is already designed to handle multiple tables and the relationships between them, and will look after assigning a unique reference to each new record you add. It takes a bit more effort to set up, but once done it massively reduces the ongoing effort required.

Paradoxically the more you break information down into separate tables in a relational database, the easier it is to manage the data. This works seamlessly in a relational database, but quickly becomes unmanageable with spreadsheet tables.

Taking the MI problem, many people could be mentioned in one MI, which could be one of many MI's in one cemetery. The solution you are working on is to add one record into a spreadsheet table per person mentioned in the MI, which results in some information having to be entered multiple times and more data to manage.

With a relational database you could ideally split the data into three separate tables - Cemeteries / Memorials / People. Meaning you have one record for the cemetery, one for the memorial/marker, and one for each person named on that memorial/marker. The database will take care of the linkages and present the data to the user as if it were one single complete record per person.

Apologies if that is far more information than you wanted, or if it has confused things. But from my own experience I discovered that time spent getting the structure right at the start saves many headaches later, so would recommend finding out/thinking about the database you'll use in the future, even though starting with data entry in spreadsheets could be fine for now.  :)


Offline andrewalston

  • RootsChat Aristocrat
  • ******
  • Posts: 2,932
  • My granddad
    • View Profile
Re: Software for strays
« Reply #4 on: Thursday 13 May 21 12:03 BST (UK) »
I think you may be overcomplicating things for the the purpose Mad01 describes.

What you are describing is the workings of a FH application. The one I use works just this way. I am person number 1 in my own tree, and the database holds various tables of names, places, events etc.

The trouble with this approach is that it becomes difficult to move the data to a fresh system later on, and that is Mad01's intention.

The FH Society's web hosting will almost certainly provide means of setting up a database, but the architecture may not be what you are used to, and if you are going to spend time learning how to use database concepts, that is the environment where it would be most profitable.
Looking at ALSTON in south Ribble area, ALSTEAD and DONBAVAND/DUNBABIN etc. everywhere, HOWCROFT and MARSH in Bolton and Westhoughton, PICKERING in the Whitehaven area.

Census information is Crown Copyright. See www.nationalarchives.gov.uk for details.

Offline Nick_Ips

  • RootsChat Veteran
  • *****
  • Posts: 541
  • Census information Crown Copyright, from www.nationalarchives.gov.uk
    • View Profile
Re: Software for strays
« Reply #5 on: Thursday 13 May 21 13:05 BST (UK) »
I think you may be overcomplicating things for the the purpose Mad01 describes.

What you are describing is the workings of a FH application. The one I use works just this way. I am person number 1 in my own tree, and the database holds various tables of names, places, events etc.

I was afraid the way I was describing things would make it sound too complicated - the point I was trying to make is the power and flexibility of databases vs spreadsheets and that the (sometimes significant) effort required to set things up to start with is repaid by fewer problems later.

What I've actually done is to create a database of census records, a database of MI's, a database of BMD's etc, and then have an overarching database of individuals (and the relationships between them) which connects the different sets of data together and presents the information in a useful way.

I think my database of MI's is the equivalent of what Mad01 is seeking. It contains lots of MI's, not all of which have any connection to people I'm related to. It is a store of information of a particular type which might (or might not) be useful one day.

The trouble with this approach is that it becomes difficult to move the data to a fresh system later on, and that is Mad01's intention.

The FH Society's web hosting will almost certainly provide means of setting up a database, but the architecture may not be what you are used to, and if you are going to spend time learning how to use database concepts, that is the environment where it would be most profitable.

Very much my point. To avoid problems and hard work later it is important to see where you want to get to in the end, and then design what you do today to make it easier to migrate to whatever it is you will finally use.

Offline Mad01

  • RootsChat Extra
  • **
  • Posts: 24
  • Census information Crown Copyright, from www.nationalarchives.gov.uk
    • View Profile
Re: Software for strays
« Reply #6 on: Thursday 13 May 21 19:48 BST (UK) »
Hi
Thank you to you both. Did not realise how complicated setting up a database for strays could be. I am going to have a serious think of how I want this to look like before I go any further and I will have a chat with the people responsible for maintaining the website to see what can be done.

Thank you again

Ann

Offline Nick_Ips

  • RootsChat Veteran
  • *****
  • Posts: 541
  • Census information Crown Copyright, from www.nationalarchives.gov.uk
    • View Profile
Re: Software for strays
« Reply #7 on: Thursday 13 May 21 20:23 BST (UK) »
Thank you to you both. Did not realise how complicated setting up a database for strays could be. I am going to have a serious think of how I want this to look like before I go any further and I will have a chat with the people responsible for maintaining the website to see what can be done.

Sorry Ann, I hope I haven't caused confusion here. The database doesn't have to be complicated, it just needs to be suitable for what you eventually want to do with it.

But giving extra thought to what you want to achieve, and talking to others involved, is definitely the right way to go.  :)

Offline Zaphod99

  • RootsChat Senior
  • ****
  • Posts: 261
  • Census information Crown Copyright, from www.nationalarchives.gov.uk
    • View Profile
Re: Software for strays
« Reply #8 on: Thursday 13 May 21 22:59 BST (UK) »
I'm probably thick, but what is MI? Missing individual. Monument inscription?  Missing in action? They all might fit.

Zaph