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.