Databases Reference
In-Depth Information
The disadvantage is that we have taken a single schema and just broken it up
into multiple manageable files. But apart from this, we still have all the other
disadvantages that we outlined previously when creating a single master model.
The major disadvantage is that if we change any single document, we change the
entire model. This would result in a new version of the entire model, and thus for us,
potentially having to update every single service implemented to date.
Multiple namespaces
The other approach, of course, is to define a namespace for each individual domain;
each schema can then reference a definition in other schema's by making use of the
xsd:import
element. This is the approach we have taken for oBay and is illustrated
as follows:
With this approach, we have no master schema, thus services only need to import
the parts of the canonical model which are relevant to them. Whilst with the
single namespace approach, you will typically end up being required to import
the entire schema.
Another advantage of this approach is that it allows different groups to be
responsible for each namespace, and for each namespace to evolve to a certain
extent, independent of others.
The drawback to this approach is that instance documents become more complex, as
they will need to reference multiple namespaces. To prevent this from becoming a
problem, it's important to partition your data model into sensible domains and also
resist the urge to over partition it and end up with too many namespaces.
