Hi Markus,
this is a common design issue then content management meets product databases ;
-)
Generally, there are two possibilities:
1. Region centric
2. Product centric
In option 1. you assign products to a region.
Pro: each region can be setup individually ( and independently)
Con: (potential) duplicate Content (product data).
This is similar what you do currently with the region based
installations
In option 2., you focus on the products but you have to model the region
specific variants (content). The challenge is to figure out the rules to model
the variants and to keep them easy to maintain.
The solution depends also on the rate "technical-info" vs "Product-Description
/Marketing info"
Depending on your customers requirements, it may a good idea to split the
system into to loosely coupled Systems: Product DB <-> Content management (
Product-Description /Marketing info )
> Am 29.09.2015 um 17:35 schrieb Markus Ruggiero <[email protected]>:
>
> 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---
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list ([email protected])
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/webobjects-dev/bock%40salient.de
>
> This email sent to [email protected]
Mit freundlichem Gruß,
René Bock
Software Engineering
--
salient doremus
salient GmbH
Kontorhaus - Lindleystraße 12
60314 Frankfurt Main
Fon +49 (0)69 - 650096 -0, Durchwahl: - 18, Fax: -70
http://www.salient.de
http://www.doremus.com
http://www.openforms.de
Geschäftsführer: Peter Biler, Alexander Gerling, Lars Ohlerich
Amtsgericht Frankfurt Main, HRB 48693
// Neuer Schwung auf allen Endgeräten für den Automobilclub von Deutschland:
http://www.avd.de/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
