Data modelling
Data modelling in Entity Framework
-
Logs
1.1.1. Log table All transactions should generate events, and the events stored in an event store. The transactions (API calls, ORM calls etc.) can be stored in a NOSQL database and analyzed in…
-
Entity configuration
The main configurations for data access will be done with the ORM syntax (indexes, entity structure etc.) and the display options will be in a DB table in order to allow the user…
-
Entity Attribute Value
Entity–attribute–value model (EAV) is a data model to encode, in a space-efficient manner, entities where the number of attributes (properties, parameters) that can be used to describe them is potentially vast, but the number that will…
-
Extensions
Extending the models Extensions should only be used for customer specific implementations that don’t make sense to be added to the main default business models. Each model should have a property named extension.…
-
Field types
The entity fields should be in one of the following categories: id (usually indexable) primitives (int, string, decimal) list of primitives other entity owned only by the parent (example: unit of measure) list…
-
Named entity
It is an entity that implements the descript able entity and features a field (string) called name. Use it to implement Enums (see below). Enums Postgres and TypeORM support enums. Business logic will…
-
Base entity
Base entity The entity base class will have the following mandatory fields: id (always primary key) deleted (soft delete flag) extension (custom fields requested by the implementation)
-
Cache
Some fields and entities could be marked as cacheable. Those entities will be refreshed when a modify operation took place on that specific entity. For example, an updated event is raised for an…
-
Base entities
All entities will have the soft delete implementation. The base data access implementation will take care to only read the non-deleted entities. All entities will be implementations of a base class that will…