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. -- Mailing list: https://launchpad.net/~savoirfairelinux-openerp Post to : [email protected] Unsubscribe : https://launchpad.net/~savoirfairelinux-openerp More help : https://help.launchpad.net/ListHelp
