I am curious where you think categories might fit with regard to database tech - cats kinda live in the space between code and data so they don't really fit with trad databases or trad code
https://multix.substack.com/p/solving-data-integration-with-...
Not sure if the Q was directed at me, but I just skimmed your write-up. Here is a new word to add to 'logic, data, coding': mapping. ETL is mapping wrapped in IO, is it not? Btw, { data, computation, mapping, and interaction (aka 'glue') } seems to cover all the bases for me.
So, on one hand, we have structured, semi-structured, and unstructured source of truth silos of information that we seek to unify (which is the case you are considering). The other possibility is an unstructured pool of data that is annotated to some degree with metadata, from which we can derive (online or offline, as necessary) application specific 'databases'. Naturally the latter case is a better fit for greenfield systems, and the former the 'legacy' of ad-hoc growth.
I don't think anyone would seriously object to viewing the act of mapping elements from one set to another - the T of ETL - as application of functions, for that's precisely what it is. (Don't really know anything about C.T. to have an informative input in that regard.)
So, on one hand, we have structured, semi-structured, and unstructured source of truth silos of information that we seek to unify (which is the case you are considering). The other possibility is an unstructured pool of data that is annotated to some degree with metadata, from which we can derive (online or offline, as necessary) application specific 'databases'. Naturally the latter case is a better fit for greenfield systems, and the former the 'legacy' of ad-hoc growth.
I don't think anyone would seriously object to viewing the act of mapping elements from one set to another - the T of ETL - as application of functions, for that's precisely what it is. (Don't really know anything about C.T. to have an informative input in that regard.)