It's interesting how different people fall into different "everything is a hammer" perspectives. I have a bunch of people around who do the same, everything collapses into table-like structures, but personally I always end collapsing everything into a tree, one way or another. Any problem I encounter, my brain seems to just default into "Yeah, arranged this way, this is clearly just a tree", and it keeps happening for stuff.
And for me, tables are just trees, but for them, trees are just tables.
A tree encodes a mandatory path or navigation to get to some piece of data. But not every piece of knowledge has a "true" path.
Whereas a relation ("table" in its crude form) can be queried and projected into many forms (including as a tree) but with multiple paths to the same data and ensure future uses are not trapped in a mandatory hierarchy. This was Codd's entire discovery and it still holds 50 years later.
And eventually tis all the same in the end, and in the beginning. To me all is grammars and program states eventually, and recursion, and prolog and all are diffrent perspective of the same concept/phenomenon.
Is there a higher-level abstraction than parametric grammars nagivating program states...?
As a sidenote, it seems think Stephen Wolfram has similar take on things, but like taken to extremes and applied to dynamic systems. His idea is that all that we experience is a byproduct of some ever-unfolding energies governed by parametric rules. Thus Ruliad. Though his thing sounds less plausible than what we (already) have (applied and working) in classic computing.
idk...
btw, table rows ar facts from PROLOG perspective and much of what SQL stands on is PROLOG. the parametric rules with conjunctions part is in the WHERE clause if one ever wonders... took a while for me to figure it out.
p.s. graphs are represented very often by means of tables, relations if u want. trees are graphs. then, on the other hand, we use trees to index table-storages. so the connection/mapping is there all the time.
And those trees are usually represented as tables via an array of structs or similar. IMHO, the architecture of memory and memory access should push us more towards tables as a default data structure than trees.
As long as there are no self loops, then you can represent a graph with a set of spanning trees that cover the edges. This is particularly efficient when using a depth or parent vector tree representation and is seen in HPC applications.
Data-oriented programming suggests if you can structure your program as a series of transformations over tables, it'll be fast, but if it's a series of transformations over trees, it'll spend all its time waiting for cache misses.
Comments
It's interesting how different people fall into different "everything is a hammer" perspectives. I have a bunch of people around who do the same, everything collapses into table-like structures, but personally I always end collapsing everything into a tree, one way or another. Any problem I encounter, my brain seems to just default into "Yeah, arranged this way, this is clearly just a tree", and it keeps happening for stuff.
And for me, tables are just trees, but for them, trees are just tables.
A tree encodes a mandatory path or navigation to get to some piece of data. But not every piece of knowledge has a "true" path.
Whereas a relation ("table" in its crude form) can be queried and projected into many forms (including as a tree) but with multiple paths to the same data and ensure future uses are not trapped in a mandatory hierarchy. This was Codd's entire discovery and it still holds 50 years later.
And eventually tis all the same in the end, and in the beginning. To me all is grammars and program states eventually, and recursion, and prolog and all are diffrent perspective of the same concept/phenomenon.
Is there a higher-level abstraction than parametric grammars nagivating program states...?
As a sidenote, it seems think Stephen Wolfram has similar take on things, but like taken to extremes and applied to dynamic systems. His idea is that all that we experience is a byproduct of some ever-unfolding energies governed by parametric rules. Thus Ruliad. Though his thing sounds less plausible than what we (already) have (applied and working) in classic computing.
idk...
btw, table rows ar facts from PROLOG perspective and much of what SQL stands on is PROLOG. the parametric rules with conjunctions part is in the WHERE clause if one ever wonders... took a while for me to figure it out.
p.s. graphs are represented very often by means of tables, relations if u want. trees are graphs. then, on the other hand, we use trees to index table-storages. so the connection/mapping is there all the time.
I'm sure you've stumbled upon graphs that are not trees, which can be represented with tables.
But on the other hand table are represented with trees![1]
[1]: https://en.wikipedia.org/wiki/B-tree#B-tree_usage_in_databas...
And those trees are usually represented as tables via an array of structs or similar. IMHO, the architecture of memory and memory access should push us more towards tables as a default data structure than trees.
As long as there are no self loops, then you can represent a graph with a set of spanning trees that cover the edges. This is particularly efficient when using a depth or parent vector tree representation and is seen in HPC applications.
Everything can be a tree with a single node that stores a blob of the data in whatever format you want.
Data-oriented programming suggests if you can structure your program as a series of transformations over tables, it'll be fast, but if it's a series of transformations over trees, it'll spend all its time waiting for cache misses.