3 ms·

Why not to trade a multitude of "custom" database managers for a single well-designed distributed database manager? It's not clear whether the author is arguin

Why not to trade a multitude of "custom" database managers for a single well-designed distributed database manager? It's not clear whether the author is arguing that all existing OS data structures should be replaced with a single database system, or if they simply want all OS data to be capable of being queried/updated via a standard database style interface. The former is simply hubris ("I know the perfect data structure for EVERYTHING!") while the latter is pretty much implementable as an interface layer on top of an existing OS.

miltondts 7y ago
That's the beauty of the relational model, it doesn't specify data structures. Those can be added later by indexes. For more info check https://www.researchgate.net/publication/2364452_Data_Structures_Considered_Harmful https://www.researchgate.net/publication/2364452_Data_Struct...
- smallnamespace 7y ago
  The set of indexes are a form of data structure though, with all the state juggling and heuristics that usually go along with them (What access pattern requires this index? When do I have too many of them? What locks when I add/drop an index?). This adds complexity and unpredictability to the user.
  - taffer 7y ago
    I would argue that dropping and creating indexes is much less work than refactoring large parts of your codebase just to change a data structure. Also, you can have multiple indexes on a table and the RDBMS ensures that they are always synchronized, which is something you won't achieve if you code the data structures yourself.
- mamcx 7y ago
  This is the key. You can even say that we only have a small amount of abstract "shapes" of data: Scalars, list, tables(relations), tree/graph. You can build generalized operations on them and it will work even if the internal structure (ie: list can be done on top of vectors or linked list or tables or tree) differ. This is what I working on in my own little language (http://tablam.org http://tablam.org). Certainly requiere specialize per structure and some stuff is hard to generalize but the idea hold.
jayd16 7y ago
There's another aspect to this that seems almost tangential as well. The author goes into the idea that program imports are directly referenced at the OS level. I suppose this replaces compiled system calls with some kind of foreign key reference? The author mentions this removes the need for ids, but really it would just be hiding them in a non-serializable way.

miltondts 7y ago

That's the beauty of the relational model, it doesn't specify data structures. Those can be added later by indexes. For more info check https://www.researchgate.net/publication/2364452_Data_Structures_Considered_Harmful https://www.researchgate.net/publication/2364452_Data_Struct...

smallnamespace 7y ago
The set of indexes are a form of data structure though, with all the state juggling and heuristics that usually go along with them (What access pattern requires this index? When do I have too many of them? What locks when I add/drop an index?). This adds complexity and unpredictability to the user.
- taffer 7y ago
  I would argue that dropping and creating indexes is much less work than refactoring large parts of your codebase just to change a data structure. Also, you can have multiple indexes on a table and the RDBMS ensures that they are always synchronized, which is something you won't achieve if you code the data structures yourself.
mamcx 7y ago
This is the key. You can even say that we only have a small amount of abstract "shapes" of data: Scalars, list, tables(relations), tree/graph. You can build generalized operations on them and it will work even if the internal structure (ie: list can be done on top of vectors or linked list or tables or tree) differ. This is what I working on in my own little language (http://tablam.org http://tablam.org). Certainly requiere specialize per structure and some stuff is hard to generalize but the idea hold.

jayd16 7y ago

There's another aspect to this that seems almost tangential as well. The author goes into the idea that program imports are directly referenced at the OS level. I suppose this replaces compiled system calls with some kind of foreign key reference? The author mentions this removes the need for ids, but really it would just be hiding them in a non-serializable way.