FYI, the video still exists (but I don’t think it shows up in the standard Fibery list)
I was thinking earlier, another way to contrast the difference between abstract databases ideas and more concrete ones is by considering how normal people in a business communicate.
In a business meeting, executives might say, “I want a report on all customer orders relating to this particular product range for this date period.”
You’d be less likely to hear them say, “I want a report on all effects related to occurrences of steps for this item.”
…as it takes a different type of mind and thinking to relate to things that way.
1 Like
Are you suggesting I am not a ‘normal person’? 
But seriously, the video I shared was a summary of how I thought something could be set up in Fibery (in this case inventory management) and it’s true that there was probably a lot of trial and error that had gone before, in order to reach this point.
For example, I have previously set up systems for bill of materials, for manufacturing process tracking, for product architectural breakdown, etc. and it’s hard to pinpoint what I learned along the way that allowed me to reach the point where I could define 4 simple databases to implement a nice inventory management system.
To be fair, the example shown does have some inbuilt assumptions, which are not made explicit.
The template assumes that the items (cheese, bread, etc.) are fungible. That is to say, if you buy three packs of cheese and make a load of sandwiches from them, it is not possible to be able to distinguish which pack the cheese in any given sandwich has come from. In the real world (especially for perishable goods, but also for serialised items) this is not appropriate, and the design of the databases would probably be completely different, in order to support traceability.
Similarly, there will be times when product specifications evolve over time. What if you decide that a sandwich actually needs 30g of cheese and not 20g. You can’t just change the definition of a sandwich, since all sandwiches made up until that point have used 20g so any calculation of stock that assumes that 30g is required will give an incorrect result. So the databases would need to support version control.
Anyway, I am sort of making the point that the tool and the implementation is only as good as the level of depth of thinking that goes into the reality that you want the tool to describe.
So to a certain degree, my thought process in relation to setting up the Fibery workspace is secondary to the thoughts that go into deeply understanding the process/activity/data that I hope to document/manage in Fibery.
In a sense, I think this is what you are stating when you say this:
Indeed, this is/was a crucial observation, but I don’t know how I can explain how I got to it, other than working backwards:
What do you want to know? Stock levels
What do you mean by stock level? Well, it’s what you have bought/made minus what you have sold/used
How does something get made? Some things get taken from stock and put together to make something else
Are these events (where something gets made) repeatable and do they follow the same rules each time? Yes, and yes
… and so on
until eventually you conclude that these ‘events’ are in fact just multiple ‘occurrences’ of a particular predefined ‘step’, i.e. we need to record the date of an occurrence where an occurrence will always represent a particular manufacturing/purchasing/sales ‘step’.
And each ‘occurrence’ uses up some amount of some items, and will generate some amount of other items. Let’s call these consumption/production values the ‘effects’ of any given ‘step’. Which means that when a step occurs, we know what effect this will have on the stock level of a given item.
I don’t know if any of this is helping, but it’s so far the best explanation of what my thought process was…
4 Likes
After conducting a thorough analysis of mean dendrite allocation across various populations, I can confirm that you’ve exceed the normal range.
That was helpful and gave me good food for thought, thanks. I appreciate it.
1 Like
@Chr1sG it would be really useful to replicate the highlights UI for helper databases so that you can set the attributes without having to navigate away from the context you are in!
2 Likes
Good idea, and I agree with you 
I will check with the devs to see how hard it could be to specify that a helper database be treated like the highlight database from a UX perspective.
4 Likes