> even where these features are still possible, there's a bad tendency not to use them. Why is that, and how do we fix it? Uh... databases ~~suck~~ have terrib

> even where these features are still possible, there's a bad tendency not to use them. Why is that, and how do we fix it? Uh... databases ~~suck~~ have terrible usability issues? And so does SQL? Like, really hard core. I took some DB classes at uni and I've learned a lot since too, but no matter how many times some SQL wizard explains to me the "beauty of null," I just don't get it. Why would you want to use three-value logic when you can use two-value logic? Why doesn't SQL have custom types? I avoid almost-programming languages like the plague - if I'm gonna write a Powershell script that's longer than 50 lines, I pull out C#; if I'm gonna write a bash script that's longer than 50 lines, I pull out python; and if I'm gonna write a SQL procedure that longer than 50 lines, I do it in the application. For a job, I had to write a SQL script that, for each row with some conditions true, check the value of a string column, split it into a list of elements by commas, then split each element into pairs by a horizontal line, and return rows that had duplicate keys. Write a query that does this on MSSQL 2012. Then tell me if it works on the top five other SQL vendors. Now do it again, but instead of a string data with char delimiters, it's protobuf data. Other old programming languages like C and C++ have had their usability issues. Conflicting implementations, basic functionality missing (std::string::contains). But SQL feels .. perpetually 20 years behind. PS: Use [Kusto Explorer](https://docs.microsoft.com/en-us/azure/data-explorer/kusto/tools/kusto-explorer https://docs.microsoft.com/en-us/azure/data-explorer/kusto/t...) for an hour and then tell me SQL has lots of nice features again. I have a Pavlovian reaction just to seeing "NOT NULL"