The advantages of tables, are that you can visually or geometrically read the contents easily, whether it is reading a row and only a row, or wether it's reading the contents of a column sequentally.
While we had spreadsheets since the 90s, which visually allow the user to create tables. Relational database take this concept to the very architecture in both the storage format and as in the data retrieval mechanisms.
Relational databases define schemas with fixed length fields, and by extension each row has a fixed length. This is equivalent to the horizontal length of a column, but in terms of bytes. This allows for quickly finding the nth row of a table, or the ith field of a column.
Query languages formalize the algorithm for reading a traditional table. Going row by row checking the description of each transaction (Select * from table), comparing it to our searched term (where description = salary), then going to the column with the destination account, and looking for that in another table with a similar process.
Just that, interesting how the same metaphor lead to 2 very different types of accounting software.
"interesting how the same metaphor lead to 2 very different types of accounting software."
The tablets are tabulated lists which is how anyone might do a shopping list or list of income and expenditure.
Double entry book keeping is only around 600 years old (I'd have to look it up). That method requires an in from somewhere corresponding to an out from somewhere else. It enables or enhances all sorts of funny business and also cross checking and auditing.
Then we move on to the full Nominal/Sales/Purchase ledgers with Cashbook and all the rest. Perhaps we might instead go for the personal version.
Anyway, my point is that accounting does not depend on IT related metaphors.
The tablets in OP are tabulated tallies of works and how they were generated - it is like a spreadsheet where the human is the computer.
Funnily enough, we call them tablets instinctively. Computer originally meant a person who computed things. No need for metaphors at all 8)
DEBK is also tabular. And it's a perfect solution when you cannot (or don't want) delete or update older data. Just like when you write on clay tablets.
I wouldn't be surprised if we recover Sumerians example of DEBK tablets.
VisiCalc, the first computerised spreadsheet, was released in 1979. Presumably there were non-computerised spreadsheets, actual large sheets of paper, used for calculations before that.
My Mum's typewriters had a tab key too! You used to start a paragraph off with a tab. Personally I prefer not to.
30 odd years ago I used to teach IT skills - UK govt funded qualifications. For example the RSA Computing level 1 and 2 NVQs. RSA were the really old school based qualifications (the R is for Royal) and by old school, I mean that they were old school 30 years ago! So it was basically a typing exam.
Each folder of "evidence" - 12 units, two or three pieces of evidence each - was allowed something silly like three mistakes. A mistake includes a typo, spacing and other daft things. The units were spreadsheets, word processing, databases, email, fax and more. Each piece of evidence could be quite a lot of text. You might notice that I put two spaces after a full stop (period). That's an old habit and failure to do so is a mistake.
Obviously the world has moved on since. Did you know there are at least four types of tab stop these days? Left, right, centre and decimal. Few people know or even care about decimal tabs. You can avoid them in web dev style and use a table to emulate them, but I will notice!
Anyway the tab key is way older than IT.
(EDIT) It seems HN coalesces multiple spaces into one when displaying.
While we had spreadsheets since the 90s, which visually allow the user to create tables. Relational database take this concept to the very architecture in both the storage format and as in the data retrieval mechanisms.
Relational databases define schemas with fixed length fields, and by extension each row has a fixed length. This is equivalent to the horizontal length of a column, but in terms of bytes. This allows for quickly finding the nth row of a table, or the ith field of a column.
Query languages formalize the algorithm for reading a traditional table. Going row by row checking the description of each transaction (Select * from table), comparing it to our searched term (where description = salary), then going to the column with the destination account, and looking for that in another table with a similar process.
Just that, interesting how the same metaphor lead to 2 very different types of accounting software.