| ▲ | bob1029 5 hours ago |
| The best way to store information depends on how you intend to use (query) it. The query itself represents information. If you can anticipate 100% of the ways in which you intend to query the information (no surprises), I'd argue there might be an ideal way to store it. |
|
| ▲ | roenxi 10 minutes ago | parent | next [-] |
| Yes with the important caveat that a lot of the time people don't have a crystal ball, can't see the far future, don't know if their intents will materialise in practice 12 months down the line and should therefore store information in Postures until that isn't a feasible option any more. A consequence of there being no generally superior storage mechanism is that technologists as a community should have an agreed default standard for storage - which happens to be relational. |
|
| ▲ | alphazard 4 hours ago | parent | prev | next [-] |
| This is exactly right, and the article is clickbait junk. Given the domain name, I was expecting something about the physics of information storage, and some interesting law of nature.
Instead, the article is a bad introduction to data structures. |
| |
| ▲ | megaBiteToEat 3 hours ago | parent [-] | | You both are affirming the title of the article. "No single best way", meaning "it depends." But don't let something like literacy get in the way of a opportunity to engage in meaningless outrage. |
|
|
| ▲ | DixieDev 4 hours ago | parent | prev [-] |
| This line of thought works for storage in isolation, but does not hold up if write speed is a concern. |
| |
| ▲ | sandworm101 17 minutes ago | parent | next [-] | | Speed can always be improved. If a method is too slow, run multiple machines in parralel. Longevity is different as it cannot scale. A million cd burners are together very fast, but the CDs wont last any longer. So the storage method is is the more profound tech problem. | |
| ▲ | 3 hours ago | parent | prev | next [-] | | [deleted] | |
| ▲ | cannonpalms 3 hours ago | parent | prev | next [-] | | So long as (fast/optimal) real-time access to new data is not a concern, you can introduce compaction to solve both problems. | | | |
| ▲ | convolvatron 3 hours ago | parent | prev [-] | | as a line of thought, it totally does. you just extend the workload description to include writes. where this get problematic is that the ideal structure for transactional writes is nearly pessimal from a read standpoint. which is why we seem to end up doubling the write overhead - once to remember and once to optimize. or highly write-centric approach like LSM I'd love to be clued in on more interesting architectures that either attempt to optimize both or provide a more continuous tuning knob between them |
|
