↳ In-reply-to » I've never liked the idea of having everything displayed all of the time for all of history.

@eldersnake@we.loveprivacy.club Several reasons:

• It’s another language to learn (SQL)
  
• It adds another dependency to your system
  
• It’s another failure mode (database blows up, scheme changes, indexs, etc)
  
• It increases security problems (now you have to worry about being SQL-safe)
  

And most of all, in my experience, it doesn’t actually solve any problems that a good key/value store can solve with good indexes and good data structures. I’m just no longer a fan, I used to use MySQL, SQLite, etc back in the day, these days, nope I wouldn’t even go anywhere near a database (for my own projects) if I can help it – It’s just another thing that can fail, another operational overhead.

↳ In-reply-to » @eldersnake Several reasons:

For the record (if you don’t care, just wait for this to be evicted from the cache :-P), here’s what I said on IRC, partially sprinkled with some brief explanations I added after the fact.

It’s another language to learn (SQL)

Yes, but it’s not too terrible, you probably don’t need all the features, you stick to a simple subset of the language that can easily be learned in my opinion.

It adds another dependency to your system

Sort of. But you can omit your own archive/cache implementation in return. Provided, you use a properly tested and well-proven database, you don’t have to worry about your own invention.

It’s another failure mode (database blows up, scheme changes, indexs, etc)

That does make exactly no difference from your own stuff blowing up in your face or changing anything regarding schema or indexes. Your own cache/archive can become corrupted, too. Changing the data that will be stored means even your own solution has to deal with that as well.

It increases security problems (now you have to worry about being SQL-safe)

Same here. You have to think about that with your own implementation as well. Gotta simply have to secure your cache and archive data on disk. I probably misunderstood the part on SQL-safety, hence there was a follow-up argument on IRC:

There is no possibility of any silly SQL injection flaws

Yes, but every serious database driver has simple solutions to avoid injections. Don’t get me wrong, it is a point, but just so minor, that it can be easily addressed, esp. when components are properly cut to their responsibilities (aka there is a storage access layer that can simply escape everything, if explicitly needed).

Another advantage with a database is that there is already wide tool support out there. You don’t have to come up with your own specialized tooling in order to look into your dataset when trying to figure out what rubbish has accumulated etc. I’m just thinking about all the discussions with bad data we had in the past. As far as I understood it, initially there was no way to analyze that, custom code had to be always written first.

Having said that, I’m backing off this discussion. Please note, I don’t want to convince anybody to switch to a database, I just think these arguments are flawed (that term might be too harsh, who knows, English is not my mother tongue).

↳ In-reply-to » @eldersnake Several reasons:

@lyse@lyse.isobeef.org flawed is the right word, no harsh at all. Good reading, and thanks for supporting the possibility of convincing @prologic@twtxt.net to switch to a database! :-D :-P