Executando verificação de segurança...
4

Tenho gostado bastante das suas postagens. Tem hora que dá pra pensar se não é feita por IA, apesar de um prompt bem feito, o que já é algum mérito, mas ela é informativa, entre em assuntos que poucos entram, não costuma ter erros, especialmente crassos que muitos cometem, e queria expressar isso, eles vão ajudar muita gente.

Também queria aproveitar aqui para alertar os leitores que isso é um check list bem feito, mas ele é uma simplificação, não basta olhar essas coisas meio por cima. Para dar um exemplo, o padrão de acesso não é só olhar a porcentagem, mas a forma e distribuição disso, se é concorrente de fato ou não e vários outros pontos.

Uma coisa que não está dita é que boa parte das informações que vai encontrar sobre o SGDB A, B ou C é tendenciosa, avaliada de forma equivocada ou tem problemas mais ou menos graves. Em muitos casos pode não fazer diferença a não ser que a equipe seja boa nele, conforme falado. Mas tenha em mente que grande parte do que falam por aí sobre este assunto, outros em computação e qualquer coisa, especialmente na internet, é falso em algum nível, por exemplo que você terá que trocar de SGDB um dia (alguns raríssimos casos terá que migrar por ter feito besteira antes, outros é só a pessoa aprender usar direito).

Outra coisa que queria falar é que o SQLite é um SGDB válido para a esmagadora maioria das aplicações, trazendo enormes vantagens. E há anos eu era o maluco que falava isso, agora cada dia tem mais plataformas monstruosamente grandes o usando e provando que é mais verdade até do que eu achava. E estão criando ferramentas para minimizar ou anular as deficiências dele em vários cenários. Claro que ele não serve para tudo e é óbvio que a pessoa precisa conhecê-lo muito bem para tirar proveito dele. Mas quem sempre disse que ele só serve como brinquedo ou fazer algo absurdamente simples só demonstra publicamente que não entende de banco de dados e só sabe seguir receitas de bolo.

Raríssimo, mas criar um novo SGDB é algo que ninguém coloca como opção, provavelmente pra bem, porque se começar falar muito vai ter gente fazendo onde não deve, como acontece com muitas tecnologias.

Cada vez mais vai se provando o que eu sempre falei, você está sempre seguro adotando um bom banco de dados relacional. NoSQL é exclusivamente útil em uma quantidade pequena de cenários. Cada dia mais os DBs relacionais são capazes de entregar quase com a mesma qualidade e facilidade o que os tais NoSQL (termo horroroso que mostra como isso é mal pensado) entregam no mesmo produto. É verdade que um ou outro produto NoSQL também está tentando entregar o mesmo que um relacional, mas ainda tem muito feijão para comer e chegar perto. Eu sei que ele tem algumas limitações, é mais fácil e está mais perto do relacionais terem "tudo" que os NoSQLs têm. Estou mais confiante em falar isso porque agora tem mais estudos e provas do que a minha observação e o que a minha experiência me mostrava.

Vou aproveitar a oportunidade que quase fiz nas primeiras postagens sobre microsserviços, que foram boas que mostra que quem escreveu, não importa quem, entende do assunto, pelo menos em teoria, não tenho como avaliar a prática. Mas muitas pessoas esquecem de avisar enfaticamente que apesar dele ser uma solução válida, quase ninguém precisa dele e quase todas as adoções é só por modinha, especialmente se for por causa de escala e/ou confiabilidade, o que ainda pode ter um motivo é organizacional, ou seja, é motivo político e não técnico, é seguir a Lei de Conway em equipes com centenas ou milhares de pessoas ou ter um motivo específico raro. Até faz sentido ter alguns microsserviços em várias soluções, mas não pensar na arquitetura toda obrigatoriamente desta forma.

Um dia falarei mais sobre essas coisas no meu canal/blog, para debater o assunto, receber críticas válidas, adendos e um monte de "terraplanista" que acabou de sair das fraldas esperneando porque falei que a tecnologia que ele ama não é tudo isso.

S2


Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente (não vendo nada, é retribuição na minha aposentadoria) (links aqui no perfil também).

Carregando publicação patrocinada...
1

Geralmente (uns 90% dos casos) uma arquitetura tradicional com monólito e banco de dados relacional vai ser suficiente. Inclusive os posts que fiz sobre microsserviços é um alerta sobre a complexidade do uso dos mesmos.

Um ponto importante que quando falamos de arquitetura de software tudo gira em torno do trade-offs

1

Na verdade 90% é justasmente o que eu combato, muita gente acredita nisso e um dia vai chegar nesse número só por causa dessa crença, até porque muita gente acha que todo mundo está fazendo ms quando na verdade não estão. O que precisa, e por motivos organizacionais, é algo em torno de 0,1%, e posso estar sendo otimista, ou pessimista, é fato que ninguém tem um número correto, eu tenho minha experiência e a visão de diversos projeos complexos que nunca precisaram e provam que ms não é tão necessário quanto dizem e também tem cada vez mais demonstrações que chega um ponto que ele começa cobrar um preço alto demais e a vantagem vira desvantagem, e cada vez mais tem gente percebendo isso, mas tem gente ainda falando bem do treco. Os maiores divulgadores da técnica não mostram publicamente como eles são mais produtivos ou possuem mais qualidade, pelo contrário, talvez o caso mais famoso é uma tragédia pública.

As pessoas não sabem medir trade-offs, geralmente fazem baseado em crenças e especulações. Quase sempre, por mais bem intenciado e competente que a pessoa seja, só dá para saber oque é melhor no caso específico fazendo os dois ou mais jeitos e depois medir. Ainda assim nada garante que será algo justo que ambos foram feitos com a mesma competência ou até se a medição é válida.

Por isso o simples sempre é a opção padrão, até que se prove completamente que precisa de outra coisa. Quase ninguém faz isso.