chrisg

@jk Let's be honest, they will shoot the bird.

The world seems a bit brighter when I know that this (hella clean, btw) mashup between Slipknot's Sulfur and Spice Girl's Wannabe, exists.

https://www.youtube.com/watch?v=pm08v69vG10

@chanakya@social.screamingatmyscreen.com Huh, TIL about Malloy. Ta.

@chanakya@social.screamingatmyscreen.com As for its current dominance. The relational model was an out-of-this-world invention. It rightfully took everything by storm. That's why it dominates today, there has been nothing better _as a product_ around. Models? Meh, maybe. Docs + key/value are too simple, graphs too hard. So as long as nothing new challenges SQL, it's a nice middle ground that keeps incrementally being improved. With an immense ecosystem, from tools to uni courses, of course it's not going anywhere.

@chanakya@social.screamingatmyscreen.com To be clear - I don't think there is anything wrong, per se, with SQL. Works fine, will continue working fine, I don't see it going anywhere like the network model, for example. But it is a product of the 70s, where physical proximity of data on disk meant different things than it does today. When you executed on a single CPU, with much more expensive cycles. Does it work today? Yes. Can we do better, with a redesigned model? Also yes. (Did NoSQL achieve this? I think not)

@fallenhitokiri@social.screamingatmyscreen.com Ah right, of course, I can do that. Thank you 😃

@fallenhitokiri@social.screamingatmyscreen.com

Unrelated - Hugos standard RSS location is hard to guess on mobile, needed my desktop to inspect source

Thank you for this, I didn't know. What is the expected location?

@fallenhitokiri@social.screamingatmyscreen.com For simple schemas I agree, tables work fine. But if, for example, you want fast traversals on thousands of joins, a graph dbms wins. If you want simplicity of design, docs are the way to go. To me, "performance" is not just ms/query. It's also about $/query. Ease of use. Tunability/adaptability. Schema extensibility. Federation. I am sure you can tell me of RDBMSs that have these. No doubt. The question I have is can we make a new _model_ that supports these things.

@fallenhitokiri@social.screamingatmyscreen.com I agree, SQL has kept up with the times. I guess your argument is "if it ain't broke, don't fix it", which is fair. But, I think hardware has moved on qualitatively from the 70s and 80s, and it's a legitimate question whether relational is still the best architectural model for it. The models (and their implementations) that came out in the 00s (docs, graph etc) didn't answer that question. So we need to keep trying. I wrote about this here: https://radiki.dev/posts/glowdust-intro/

@fallenhitokiri@social.screamingatmyscreen.com SQLite is an excellent piece of software, but it doesn't fit my description. I think SQL's time is past. We need new models, made for today's hardware. And I want a new license, one that lets you use the software only if you are building a community. I don't want to let software continue being appropriated by corporations. As for where federation should live - depends on what you mean by "app layer" and "storage". I think it best fits at the query language level.

@fallenhitokiri@social.screamingatmyscreen.com Hey, I wrote a whole thing about exactly this idea. It makes me so happy to see others say this too. https://radiki.dev/posts/a-small-dbms/