Database Design
From Harmoni
Contents |
Guidelines
The Harmoni services are (where possible) designed to be independent of each others' implementations and rely only on the interfaces of other services. There are a few notable exceptions to this, in particular the Authentication and Agent implementations are currently coupled to each other.
Service Independence
Similarly, the database tables used in by the service implementations should be independent of each other and queries should not join across tables belonging to different services.
Exceptions
At the time of this writing there are a few exceptions to the independence of tables and services.
- The IsAuthorizedCache in the Authorization implementation violates the independence of services by joining tables across from the Hierarchy service and the Authorization service. This was done for performance reasons and may be changed in the future if a better-performing system/design can be made.
- The 'type' table is currently used by a number of services. Each should really be maintaining their own tables of types.
Table Naming
Table names should be prepended with a code (such as 'az_' for the authorization service) to signify which implementation they are used by.
Exceptions
- Hierarchy tables are not prepended with a code. This is a historical oversight that has not yet been corrected.
Column Naming
Column names should be lowercase for portability reasons. Foreign-key columns should be prepended with 'fk_' to indicate their purpose.
An example of this are the fk_agent and fk_node columns in the log_agent and log_node tables of the Logging implementation. These columns contain the ids of Agents from the Agent implementation and Nodes from the Hierarchy implementation that are assumed to be useful of the client, though the Logging implementation will never validate them or do lookups in the other services table using them. It is up to the client to pass these ids to the appropriate Agent or Hierarchy implementation in order to validate the ids or find other information about these resources.
It may be more appropriate to use a prefix other than 'fk_' for these sudo-foreign-keys, but this change will need to be addressed in future releases.
