# I am the Watcher. I am your guide through this vast new twtiverse.
#
# Usage:
# https://watcher.sour.is/api/plain/users View list of users and latest twt date.
# https://watcher.sour.is/api/plain/twt View all twts.
# https://watcher.sour.is/api/plain/mentions?uri=:uri View all mentions for uri.
# https://watcher.sour.is/api/plain/conv/:hash View all twts for a conversation subject.
#
# Options:
# uri Filter to show a specific users twts.
# offset Start index for quey.
# limit Count of items to return (going back in time).
#
# twt range = 1 14
# self = https://watcher.sour.is/conv/ubd4zpa
@prologic not me mate, I asked as I was genuinely curious and as someone who only really knows SQL as far as databases go, I keep wondering what life is like on the NoSQL side of the fence 😅
For me personally I find it far easier to reason about the data I'm dealing with, what forms it needs to take and what to do with it.
For me personally I find it far easier to reason about the data I'm dealing with, what forms it needs to take and what to do with it.
For me personally I find it far easier to reason about the data I'm dealing with, what forms it needs to take and what to do with it.
For me personally I find it far easier to reason about the data I'm dealing with, what forms it needs to take and what to do with it.
a large part of this comes from experience, dealing with databases, and SQL many times in the past, and then eventually coming to the realizing that everything is basically key value, stores, bloom filters, trees*, tries and various types of indexes and caches.*
a large part of this comes from experience, dealing with databases, and SQL many times in the past, and then eventually coming to the realizing that everything is basically key value, stores, bloom filters, trees*, tries and various types of indexes and caches.*
a large part of this comes from experience, dealing with databases, and SQL many times in the past, and then eventually coming to the realizing that everything is basically key value, stores, bloom filters, trees*, tries and various types of indexes and caches.*
a large part of this comes from experience, dealing with databases, and SQL many times in the past, and then eventually coming to the realizing that everything is basically key value, stores, bloom filters, trees*, tries and various types of indexes and caches.*
@prologic you're just reinventing relational databases with a lot of that stuff though. Row stores are pretty bad but column stores have a huge number of advantages and are superior to keys value stores in certain cases, like when you do have a fairly strictly tabular dataset with multiple distinct concepts and want to flexibly query it without the rigmarole of reindexing every possible combination of fields you may want to query like you'd do in a key value store. Choose the right tool for the job etc.
@abucci Maybe maybe not. Depends on what you're doing I guess. For small things I find simple things are better anyway. KV, flat files, a log, etc.
@abucci Maybe maybe not. Depends on what you're doing I guess. For small things I find simple things are better anyway. KV, flat files, a log, etc.
@abucci Maybe maybe not. Depends on what you're doing I guess. For small things I find simple things are better anyway. KV, flat files, a log, etc.
@abucci Maybe maybe not. Depends on what you're doing I guess. For small things I find simple things are better anyway. KV, flat files, a log, etc.