I believe there is no correct answer in either RDBMS (SQL) or NoSQL. The design of the data will always depend on the purpose of your system.
If you are developing something that catalogs geographical entities (cities, streets, neighborhoods) type Google Maps or some delivery service, then it may make ultra-normalize sense to the street level and block.
On the other hand, if you are only collecting customer addresses, and only need a single address, type Charges Address , it would be much simpler to put the address , , city , parent in the client table itself.
Likewise it is in the mongo. You can store collections of cities, neighborhoods, etc. (eg a {_id:1, nome: 'Centro', cep: '12345-123', id_cidade: 123}
neighborhood) and refer to another collection (ex: {_id: 456, nome: 'Restaurante da Praça', endereco: {rua: 'Av Tancredo Neves, 333, sala 14', id_bairro: 1} }
client). Or you can just nest everything (ex, client {_id: 456, nome: 'Restaurante da Praça', endereco: {rua: 'Av Tancredo Neves, 333, sala 14', bairro: 'Centro', cidade: 'Patópolis', uf: 'XY', pais: 'Disney World', cep: '12345-123'} }
).
In both cases (relational x nosql) there are advantages and disadvantages. It is up to you to analyze factors such as how and how often this data will be accessed and modified, impact on application performance, data maintenance difficulty, disk data size, etc.
My advice goes to start simple, revisit and improve if you need .