| Hi WOnderers,
I am in need for some coneptual modelling advice. Let me try to explain what I want:
I am working on a product database application. Each product has a couple of attributes like product code, name, etc. For each prodcut we also have a set of electronic documents like spec sheet(s) and regulatory data. All these documents are built from a set of predefined standard text elements.
The customer today deploys this application for different geographical regions (EU, USA, etc). The code and the database structure is the same for every region. The app can handle some minor regional differences in processing (the app kows for which region it is installed). However the data is partially region specific. Some products are not available everywhere, some textblocks have region specific text and some product attributes might have region specific values (e.g. the product name could have a regional tint as well as other attributes might have region specific values). Every user of the application has an assigned region. The split deployment as of today makes region specifics completely transparent. The problem is that there will be more and more regions and the global product data management becomes a PITA with all the duplicated databases.
What we need tomorrow is ONE code and ONE database that allows for regional variations depending on the logged-in user. We could have regional variants of product data, regicon specific products, region sepcific product catalogs, region specific documentation per product, etc. The customer wants to be able to "switch region" for a super user so the global, non-region-specific stuff can be maintained centrally.
How would you model such a beast? I want this to be as transparent as possible to the code of the app (and to me as the programmer). So the region layer should be implemented as low as possible.
Thanks for any input ---markus---
|