Background
The proposal for flecsimo implies that it should be possible to run areas and cells within different sites or areas. Since every component runs it's own persistent operational database and every object id (like order numbers and sfcu id's) is only unique at the site from which the data originates, primary key conflicts may occur, if a component is used within a different site. This nay for example happen if an area 1 is operated in a site 1, where it receives (on stores) an SFCU with SFCU id = 4711. If this area 1 is moved afterwards to a site 2, this site could accidentally create an SFCU id 4711 as well which would lead to primary key constraint violation in the database of area 1.
Decided Solution
The "namespace" or "origin" of every "id" has to be part of the primary key. It seems to be natural in the context of manufacturing to choose the "site" as this namespace identifier, i.e. every table which may be used in a different context have to implement this "site"-column.
Notes: the solution is similar to the data separation in "client" aware business information systems like SAP ERP, where the Primary Key column MANDT (as German "Mandant") separates data from different clients. Whereas this client separation approach aims to allow a user only to see data of one client at a time, the site Primary Key works as a namespace, which implies to deal with data of different site at a time. As a Use Case consider an area of cells which offers operations to varying sites 
(see discussion below).
Action items
- Publish decision
Kommentar
Ralf Banning sagt:
To be precise: this solution does not necessarily enable applications to handle data from different sites simultaneously. In fact, most of the current version area- and cell-agents will only select data which is prefixed with the site-id on which the agent is running currently, i.e. they won't even "see" data from other sites. The only thing which is guaranteed by having the site-identifier in the data is, that moving around areas and cells to different sites, the database will not get corrupted by non-aligned primary keys.