At some point accounting software became the model for data and transactions on the web. We see this in the idea of addable, comparable fields, stored is a relational db design whose prime skill is accounting joins and column aggregations.
It’s Ward Cunningham who first turned me onto to this in an inspired rant of one of his dozen definitions of “wiki” — “Wiki is the simplest possible database that could work.” What did he mean by that? I asked him.
Roughly, something like this — the databases we currently use were built for numbers, under principles that work for accounting — everything must be defined as narrowly as possible. This is a text field with 255 characters. This is a float. This is an ID that will join with that 255 character description, etc.
This makes a lot of sense when you are generating expense reports, but it is particularly lousy for capturing community knowledge, because it assumes that the database designer can anticipate what knowledge the community will want to capture.
Reducing structure makes it marginally harder to run reports, and sum totals, but it results in more information being captured and displayed, and allows for end-user experimentation when dealing with novel situations. So part of the question has to be whether we see our systems as something to inform and build community or something to run reports with.
My personal opinion is if you could ban the question “can we run a report on that” from vendor sales meetings you would end up with much better software. What we have now is reporting software that treats users as an afterthought.