savoirfairelinux-openerp team mailing list archive

[Pedro Manuel Baeza <pedro.baeza@xxxxxxxxx>]

Hi, Raphaël, sorry again for another late reply.

Indeed, in Spain we have opted for a denormalized model, having more than one entity for one city. In the best case, you have 1 city, 1 record. In other cases, 1 city, n records. We thought about a totally normalized model: country -> 1..n -> state -> 1..n -> city -> 1..n -> zip, but this made all needlessly complicated, with a lot of models, screens, rules, and so on.

I think this approach is valid for all: if you want, you can denormalize to have more than one zip; if you don't want, you don't fill zip field and use 1 city, 1 record. IMHO, the purpose of having a universal city model is not needed. If you are thinking about EDI, it fails when you get a DB with the corresponding country cities not loaded. So, I consider more this module as a wizard that helps to autocomplete location fields (that's why we put the name base_location, not base_city). But let me know if there is another purpose for this normalization that I can't figure out.

Regards.

P.S.: Thank you for the SQL tip, I will try as soon as possible to see the improvement.
-- 
https://code.launchpad.net/~savoirfairelinux-openerp/partner-contact-management/city-move/+merge/196023
Your team Savoir-faire Linux' OpenERP is subscribed to branch lp:~savoirfairelinux-openerp/partner-contact-management/city-move.