>>One thing to keep in mind - what's "user" in your case? The whole of all users within one customer entity, or any individual? The difference is in the way you should store these - if there are many users with their own regionalizations, you'd have to have a regions-per-user table as a parent to keep the region names, and city-per-region-per-user as a child table; if there's only one regionalization per customer, you need only the first one, and only add the region code into cities table.
>>
>In my first message I didn't say the whole truth :) There are four applications actually involved.

Still, this doesn't answer the question on top of the quote above, which will only influence your solution in the end. If your four apps impersonate different users in this case, i.e. they have regionalizations of their own, or if they all use the same regionalization - that's something which will influence the way you'll store the city-belongs-to-region data.

It's really tough to be talking about things like this at an abstract level, because we tend to use some real-life situations and/or entities just to symbolize certain types of use or relations between entities etc, which is helping in a way, but also distracting. I can't seem to find a common denominator for all of cases like that - sometimes we do get the message through really easy, sometimes we have to pull up the details like you just did, and still aren't sure the message got through :).

Well, I hope all of this talk gives you a good headstart. Good luck.