Pequenas mudanças no model de município.

[george-silva]

alterando uf_sigla em municipios de um campo específico para uma propriedade.

Vejam se é viável/interessante.

[cadu-leite]

2012/7/25 George Silva reply@reply.github.com:

alterando uf_sigla em municipios de um campo específico para uma propriedade.

Vejam se é viável/interessante.

é sim Geoge,

Os códigos de cadastros usam a tabela Municipio somente, e outro código que use somente UF estaria errado de qualquer maneira. (vi uns sleect box com uf)

Eu só vou comentar com o Nando, que alterou essa app recentemente, porque tenho certeza que este campo já era uma FK e quero entender porque houve alteração.

Salvo engano meu, existiam 2 campos nesse model: 1 - uf -FK 2 - uf_sigla char

porque nao deixar somente o 1 ?

hoje a tarde lhe dou uma resposta.

Carlos Leite ZNC Sistemas +55 12 3905 24 05

[george-silva]

Exato. Foi esta a mudança que fiz no meu repo e dei um pull request.

Abraços

2012/7/25 Carlos E. C. Leite < reply@reply.github.com

2012/7/25 George Silva reply@reply.github.com:

alterando uf_sigla em municipios de um campo específico para uma propriedade.

Vejam se é viável/interessante.

é sim Geoge,

Os códigos de cadastros usam a tabela Municipio somente, e outro código que use somente UF estaria errado de qualquer maneira. (vi uns sleect box com uf)

Eu só vou comentar com o Nando, que alterou essa app recentemente, porque tenho certeza que este campo já era uma FK e quero entender porque houve alteração.

Salvo engano meu, existiam 2 campos nesse model: 1 - uf -FK 2 - uf_sigla char

porque nao deixar somente o 1 ?

hoje a tarde lhe dou uma resposta.

Carlos Leite ZNC Sistemas +55 12 3905 24 05

---

Reply to this email directly or view it on GitHub:

https://github.com/znc-sistemas/django-municipios/pull/6#issuecomment-7247100

George R. C. Silva

Desenvolvimento em GIS http://geoprocessamento.net http://blog.geoprocessamento.net

[luizvital]

O campo uf_sigla aqui está para evitar um query a mais para cada município para montar uma lista. Claro que pode ser resolvido com Municipio.objects.all().select_related(), mas talvez não seja óbvio para um usuário que não saque das internas dos modelos.

Como estes dados normalmente não sofrem operações de Create e Update, são importados via management command do IBGE, acredito que essa desnormalização não seja um problema. Para facilitar é possivel customizar o save ou signal pre_save para alimentar este campo automaticamente, por exemplo.

Ou ainda, somente customizar o manager para que a default QuerySet seja usando select_related. É um join a mais no banco e por isso ainda prefiro a desnormalização :D

[george-silva]

Ok, sem problemas :D

Foi só uma sugestã!

2012/7/25 Luiz Fernando Barbosa Vital < reply@reply.github.com

O campo uf_sigla aqui está para evitar um query a mais para cada município para montar uma lista. Claro que pode ser resolvido com Municipio.objects.all().select_related(), mas talvez não seja óbvio para um usuário que não saque das internas dos modelos.

Como estes dados normalmente não sofrem operações de Create e Update, são importados via management command do IBGE, acredito que essa desnormalização não seja um problema. Para facilitar é possivel customizar o save ou signal pre_save para alimentar este campo automaticamente, por exemplo.

Ou ainda, somente customizar o manager para que a default QuerySet seja usando select_related. É um join a mais no banco e por isso ainda prefiro a desnormalização :D

---

Reply to this email directly or view it on GitHub:

https://github.com/znc-sistemas/django-municipios/pull/6#issuecomment-7249145

George R. C. Silva

Desenvolvimento em GIS http://geoprocessamento.net http://blog.geoprocessamento.net

[luizvital]

Blz!

Fica avontis pra opinar.... na verdade não tem nada decidido sobre isso... so coloquei os motivos de estar assim hoje. :P

Cadu???

Luiz Fernando Barbosa Vital ZNC Sistemas

2012/7/25 George Silva < reply@reply.github.com

Ok, sem problemas :D

Foi só uma sugestã!

2012/7/25 Luiz Fernando Barbosa Vital < reply@reply.github.com

O campo uf_sigla aqui está para evitar um query a mais para cada município para montar uma lista. Claro que pode ser resolvido com Municipio.objects.all().select_related(), mas talvez não seja óbvio para um usuário que não saque das internas dos modelos.

Como estes dados normalmente não sofrem operações de Create e Update, são importados via management command do IBGE, acredito que essa desnormalização não seja um problema. Para facilitar é possivel customizar o save ou signal pre_save para alimentar este campo automaticamente, por exemplo.

Ou ainda, somente customizar o manager para que a default QuerySet seja usando select_related. É um join a mais no banco e por isso ainda prefiro a desnormalização :D

---

Reply to this email directly or view it on GitHub:

https://github.com/znc-sistemas/django-municipios/pull/6#issuecomment-7249145

George R. C. Silva

Desenvolvimento em GIS http://geoprocessamento.net http://blog.geoprocessamento.net

---

Reply to this email directly or view it on GitHub:

https://github.com/znc-sistemas/django-municipios/pull/6#issuecomment-7250471

[cadu-leite]

Em 25 de julho de 2012 16:46, Luiz Fernando Barbosa Vital reply@reply.github.com escreveu:

Blz!

Fica avontis pra opinar.... na verdade não tem nada decidido sobre isso... so coloquei os motivos de estar assim hoje. :P

Cadu???

vamos bater o martelo. porque nao vale a pena o tempo gasto.

temos que ter uma chave por isso o UF - FK e temos que ter um unicode , por isso o sigla.

Vamos manter os dois e a property sai do sigla.

É uma denormalização muito barata, pra impedir uma requisião que pde vir a ser um problema.

ou seja, se retirar o sigla, vai fazer uma enorme diferença pra montar o unicode mesmo passando pra property

Melhor deixamor como esta. (2 campos mesmo dado)

Abras. Cadu

PS: eu tinha entendido que o George estava voltando a colocar os 2 campos. 1 - uf -FK E O 2 - uf_sigla char, por isso citei o codigo antigo.

Carlos Leite ZNC Sistemas +55 12 3905 24 05