Top 9 mistakes to avoid when developing with NoSQL

Notas do Editor

• #7: Falta de ferramentas para exploração Todo mundo tem ferramentas para explorar, consultar e editar bases SQL, porém o mundo NoSQL não é tão estruturado assim!! Vejo os dados na base: Como eu desfaço operações? Crescimento desordenado Não tem as definições, limitações e restrições de um SQL tradicional, como varchar2(50) para nome Algumas bases não apagam os dados “de verdade” até você pedir – e quem te disse isso antes?
• #8: Eu acredito que esse é o maior erro quando se fala em banco não relacional. Exato, quando não utilizar um banco não relacional. Como toda tecnologia o NoSQL não é uma bala de prata e não serve para tudo! O banco relacional possui uma maturidade de décadas de mercado. Possui um padrão que permite evitar o lock-in. Manutenção fácil. Backup! Auditória Possui uma transação bem madura, é o caso de uma aplicação que precisa de controle de estoque, passagem de avião, etc. Nesses casos o uso de uma transação bem evoluída, que inclui transação alinhada.
• #14: Pense como um motor de busca. O caso clássico é buscar a informação que aparecerá numa tela de sumarização e quando se clicar no item que se deseja obter todas as informações, uma vez que se tem a informação do ID buscar tudo diretamente do banco. Por exemplo, cadastro de pessoas que retornará o id, nome e a foto, quando o usuário clicar em tal pessoa, uma vez com id ele retornará todas as informações, por exemplo, endereço, cadastro, etc. Duplicação não é malvista – use e abuse para atender as necessidades de performance
• #16: O conceito novo que vem se discutindo fortemente no mundo de microservices que é o CQRS que é o Command Query Responsability Segregation que como o nome já diz está relacionado a separar a escrita da leitura. Porém, esse conceito não pode e não deve ser considerado como algo novo ou algo a ser implementado, isso não é opcional, mas obrigatório. É importante lembrar que as aplicações no mundo NoSQL são realizadas considerando a volumetria, além de tudo, como as informações serão lidas.
• #18: O fato é que os benchmarks terão uma tendência em explorar pontos fortes do produto “aliado” e explorar pontos fracos do “inimigo”. Uma boa dica é simplesmente, criar os seus próprios spikes, verificar qual dos bancos é o melhor para o seu cenário.
• #20: Partindo do ponto do CAP e do tradicional gráfico de escalabilidade vs complexidade de modelo é importante entender que em nenhum momento você terá 100% garantia. Numa arquitetura de persistência distribuida você sempre ganhará em um ponto para poder perder em outro. Uma boa sugestão seria utilizar banco de dados para cada situação, porém, é difícil para administrar infra, além da consistência em múltiplos bancos de dados.
• #21: Partindo do ponto do CAP e do tradicional gráfico de escalabilidade vs complexidade de modelo é importante entender que em nenhum momento você terá 100% garantia. Numa arquitetura de persistência distribuida você sempre ganhará em um ponto para poder perder em outro. Uma boa sugestão seria utilizar banco de dados para cada situação, porém, é difícil para administrar infra, além da consistência em múltiplos bancos de dados.
• #22: Partindo do ponto do CAP e do tradicional gráfico de escalabilidade vs complexidade de modelo é importante entender que em nenhum momento você terá 100% garantia. Numa arquitetura de persistência distribuida você sempre ganhará em um ponto para poder perder em outro. Uma boa sugestão seria utilizar banco de dados para cada situação, porém, é difícil para administrar infra, além da consistência em múltiplos bancos de dados.
• #23: O mundo orientado objeto é algo muito rico, e conceitos como DDD e clean code, fazem seu código cada vez mais próximo do mundo real, fazendo cada vez mais valer a regra da linguagem ubiquá. Porém, apesar do seu código usar esse paradigma seu banco de dados não utiliza.
• #24: Uma dica é olhar o livro Clean architecture, ele fala de separar o que importa do seu código. Separar seu negócio da tecnologia é uma boa prática e te pode ajudar também a separar seu rich model da entidade que será inserida no banco de dados.
• #26: A base de dados é só (mais) uma ferramenta para atingir necessidade de negócio