Depois da implementação do Badger como cache durante o ETL (#173), o mesmo Badger pode ser utilizado para essas tabelas de código e nome de município, CNAE, países etc. Em termos de performance não deve ter um impacto grande (as consultas podem ser feitas em paralelo, pois são read-only, as escritas são poucas), e o código pode ser muito implificado.
Possível estratégia de implementação:
Extender newKVItem para suporte de novos sourceTypes
Extender o enrichCompany para suporte dos novos campos
utilizar o newKVitem para criar e, depois, salvar os dados das tabelas de look up no Badger no início do ETL
limpar código (que não é mais utilizado) relacionado às antigas tabelas de look up
No ETL (comando
transform
) utilizamos algunsmap[int]string
para mapear coisas como código do município para nome do muncicípio, por exemplo.Depois da implementação do Badger como cache durante o ETL (#173), o mesmo Badger pode ser utilizado para essas tabelas de código e nome de município, CNAE, países etc. Em termos de performance não deve ter um impacto grande (as consultas podem ser feitas em paralelo, pois são read-only, as escritas são poucas), e o código pode ser muito implificado.
Possível estratégia de implementação:
newKVItem
para suporte de novossourceTypes
enrichCompany
para suporte dos novos camposnewKVitem
para criar e, depois, salvar os dados das tabelas de look up no Badger no início do ETLRepetir o processo para:
motives
#217
cities
#218
countries
cnaes
qualifications
natures
ibge