Use Case Document Store
Hiperspace support for arbitrary complex models and transparent navigation between elements makes it a good match for document-oriented data models where the schema is already understood – the only difference is:
- The identity of the element must be known.
- The identity must be part of the definition – it is rare for a document not to include the moniker by which it is known. The HiLang domain language is almost identical to the equivalent typescript definition but allows parts (e.g. Address) to be stored as a value with the element or separately with transparent lookup when needed.
| TypeScript░░░░░░░░░░ | Protobuf░░░░░░░░░░ | HiLang░░░░░░░░░░ |
|---|---|---|
| class Customer = { | message Customer { | entity Customer |
| Id : number; | int32 Id = 1; | ( Id : Int32 #1) |
| Name : string; | string Name = 2; | { Name : String #2, |
| Address : Address;} | Address Address = 3;} | Address : Address #3}; |
With Hiperspace, the decision whether Address is included in the state of the Customer is determined by the definition of Address, avoiding the need to choose whether to include a key-identifier or value when modelling Customer. The same schematic translation applies to the XML Schema, but for excluded for brevity. See /tree/master/examples/Hiperspace.Sparx for an example of a large-scale document problem (UML document of a complex library), where structure is modelled directly.