4 ms·
Recently I had some related ideas, although from a completely different background. Here is what I would have done differently: 1) Implement other storages. Al
by vog 11y ago
Recently I had some related ideas, although from a completely different background. Here is what I would have done differently:
1) Implement other storages. Although databases are a natural part of web applications, a direct storage in files and/or directories may be justified. Also, for most applications the full dataset fits easily in the RAM on modern systems.
2) Keep full history. Or provide for this possibility at least. Adding history features to classic database models becomes cumbersome quickly, but for a simple schema it may be provided directly by the framework. This provides for a great audit log if something went wrong. Probably to be disabled if really unwanted and/or storage size is an issue.
Regarding the different background: Although most people want graph databases if they don't want to enforce a certain schema, my desire is the exact opposite. I want more constraints, data integrity as much as possible. I want more than can be easily reached even in PostgreSQL with user-defined functions, such as constraints across foreign keys. So a separate checker is needed, and I believe graph structure with plain links provide a good, simple base to define a constraints framework upon it.
- mikeland86 11y ago1) I like the RAM idea and in general more storage adapters. I hadn't really thought of local storage, but it makes sense for super simple prototyping. 2) I want to add DB profiling at some point (right now Libphutil does this for me at a query level, but I want to do it at a graph abstraction level). History could presumably be similar to a permanent profiler. I think constraints vs flexibility is always a tradeoff. The main benefit of this model is very rapid prototyping where design decisions can be changed or reversed with minimum effort.
- vog 11y ago> I think constraints vs flexibility is always a tradeoff. Well, that depends on the application. In the applications I have in mind, I have to make tradeoffs in the opposite direction: I know that some more constraints make totally sense. But: Is it worth implementing them, considering how hard it is to express them in the database? So I have to make tradeoffs between missing constraints and ease/feasibility of implementation. Or checking some constraints only in the application layer, but sometimes it's even more cumbersome there, than with triggers/etc. in the database.