Bob Martin está claramente exagerando para deixar seu ponto mais claro. Mas qual é o seu ponto?
Does he just want people to stop using SQL/Relational Databases because of SQLi attacks?
No meu entender, nessa postagem do blog (seu primeiro link), Martin tenta convencer as pessoas a parar de usar SQL, mas não bancos de dados relacionais. Estas são duas coisas diferentes .
O SQL é uma linguagem extremamente poderosa e é padronizada em algum grau. Permite criar consultas e comandos complexos de uma forma muito compacta, de uma forma legível, compreensível e fácil de aprender. Ele não depende de outra linguagem de programação, portanto, é útil para a maioria dos programadores de aplicativos, não importa se eles preferem Java, C, C ++, C #, Python, Ruby, JavaScript, Básico, Go, Perl, PHP ou qualquer outra coisa. / p>
No entanto, esse poder vem por um custo : escrever consultas / comandos SQL seguros é mais difícil do que escrever inseguras. Uma API segura deve facilitar a criação de consultas seguras "por padrão". Pessoas potencialmente inseguras devem precisar de mais esforço mental ou pelo menos mais de digitação. Isso é IMHO porque Martin está reclamando contra o SQL em sua forma atual.
O problema não é novo, e há APIs mais seguras do que o SQL padrão para acessar um banco de dados relacional. Por exemplo, todos os mapeadores OR que conheço estão tentando fornecer uma API desse tipo (embora eles sejam normalmente criados para outras metas principais). As variantes de SQL estática dificultam a criação de consultas dinâmicas com dados de entrada não-digitalizados (e isso não é uma nova invenção: o SQL incorporado, que usa SQL estático frequentemente, tem cerca de 30 anos).
Infelizmente, não conheço nenhuma API tão flexível, padronizada, madura, independente de linguagem e tão poderosa quanto SQL, especialmente a SQL dinâmica. É por isso que tenho algumas dúvidas sobre a sugestão de Martin de "não usar o SQL" como uma maneira realista de resolver os problemas mencionados. Então, leia seu artigo como um pensamento na direção certa, não como uma "melhor prática" que você pode seguir cegamente a partir de amanhã.