> What makes SQL bad a relational databases, and what is better? SQL is just a glorified DSL that is constrained, on purpose, to just make a SINGLE query at ti

> What makes SQL bad a relational databases, and what is better? SQL is just a glorified DSL that is constrained, on purpose, to just make a SINGLE query at time. Not for build A COMPLETE app. That is all what is "wrong" with it. SQL is assumed to be used by end-users, to make ad-hoc queries. Is like google search. It provide a minimal language but not a why to make a game engine with it. Now imagine, that search box is ALL is provided to developers to build on. And then, all the others full-text indexing libraries do the same. Surely some will extend it with some more sugar, but the fact is, "search: google OR bing" is not enough to be a useful API. That is why all developers in the world dance around SQL and kind of love-hate it. Them are not en-users and need more power, but that is only partially provided by some RDBMS as extended SQL yet the fundamental limitations hold. The only way around is using FFI with other languages because SQL is not capable enough. This is partially, and correctly, because a RDBMS is mean to be like a REST server with restricted capabilities that could lend to problems. And because RDBMS are used by non-professionals that have not clue what them are doing... and not only I'm thinking of some end-users. So make sense to restrict their damaging capabilities (so, hard to make rm -rf "/") The problem is that is ALWAYS assumed this way, even by something like sqlite. You just can't do a full app with sql, so you need to dance around with orms, stringly apis, non-type safety across the logic/tables, not why to make your own indexing strategies, nothing, or make it a REST server directly.