- I would suggest that you give yourself a chance to escape from the paradigms that you are familiar with.
- Try to “forget” about traditional databases, entities, diagrams, levels etc., and embrace the tool the way it is meant to be used.
- Otherwise, in your effort to go for simplicity, you end up imposing complexity.
- Relationships are simple arrows that connect two concepts (a reference), often through a third concept (a property).
- That produces triplets, which fill the graph database and are the targets of queries. This is:
- simple
- Certainly simpler than the traditional approaches.
- But being “new” and different, it may initially feel more complicated, while it is not.
- This doesn’t mean that every tool is made as easy as it could (Datalog for example).
- powerful
- You can quickly model complicated realities (realities are always complicated) with relatively minimal effort.
- To express such models in traditional databases, it takes nothing less than an expert.
- They often have to think in advance how the information will be used.
- In real-life systems, this is even impossible, as the needs tend to change.
- They often have to think in advance how the information will be used.
- While in Logseq:
- it is possible to start taking notes immediately, letting the exact organization to emerge
- as long as the basic principles are respected
- it still won’t happen automagically (see How to leverage Logseq’s linked structure?)
- can capture the data in a natural way, then use it in multiple ways
- it is possible to start taking notes immediately, letting the exact organization to emerge
- To express such models in traditional databases, it takes nothing less than an expert.
- You can quickly model complicated realities (realities are always complicated) with relatively minimal effort.
- simple
- That produces triplets, which fill the graph database and are the targets of queries. This is:
- CUD operations are:
- a valid concern
- currently supported only through the API
- a challenge, no matter the approach
- yet not the deciding factor for the structure to adopt
- the coming database version will make them easier
- a valid concern
- In contrast, Reading operations are already good enough, thanks to queries, which:
- are not user-friendly
- but they can achieve everything read-wise
- particularly when it comes to tag-based relations, they are not even difficult
- Concerning nesting
- Even when adopting properties, the outliner can and should be used for forming nesting views when needed.
- But they should be views on top of the actual data, not the actual data themselves.
- Consider The contextual sidebar: query current page and organize pages in indexes
- For things that are genuinely hierarchical in nature, consider Generate explicit hierarchy out of properties
- Even when adopting properties, the outliner can and should be used for forming nesting views when needed.
- The important point is to no longer just put things under other things.
Clouderaneeds its own page- preferably without a namespace
- “under” only the overall graph
- in the rare case of a name-conflict, the only fitting namespace would be
Company
- preferably without a namespace
Cloudera-Careeris not much better thanCareer/Cloudera- In your particular case, the only thing that makes sense is for page
Hal9000to haveClouderaas a value to one of its properties (employeror something). This is the intuitive association that is:- easy to maintain
- changing it won’t break things
- easy to query
- properties are straightforward
- modular enough
- can peacefully coexist with other employers
- can be the value of other properties at the same time (vendor etc.)
- easy to maintain
- In your particular case, the only thing that makes sense is for page
2 Likes