...
Foldrarna innehåller följande projekt:
skltp-ei-applicationskltp-ei-backendApplikation avsedd att driftsättas på en Mule instans med alla komponenter förutom update-service och notification-service som som ligger i frontend app'enskltp-ei-commonskltp-ei-data-modelskltp-ei-frontendskltp-ei-schemasskltp-ei-teststubapplicationsmule-backend-app
Applikation avsedd att driftsättas på en Mule instans med alla komponenter förutom update-service och notification-service som som ligger i frontend app'enmule-frontend-app
Applikation avsedd att driftsättas på en Mule instans med komponenterna update-service och notification-service.
Not: Så länge frontend-appen är uppe så kan EI ta emot uppdateringar även om backend-appen och dess databas är nere för t ex underhåll.
compositesschema
Innehåller de tjänstekontrakt som implementationen exponerar och/eller konsumerar.svc
Innehåller källkoden för verksamhetslagret samt persistenslagret.
modulesintsvc
Innehåller källkoden för integrationslagret.
...
| Kolumnnamn | Null | Primär- nyckel | Del av logisk- nyckel | Typ och Längd | ||
|---|---|---|---|---|---|---|
| id | Nej | X | Varchar(64) | |||
registered_resident_id | Nej | X | Varchar(32) | |||
service_domain | Nej | X | Varchar(255) | |||
categorization | Nej | X | Varchar(255) | |||
logical_address | Nej | X | Varchar(64) | |||
business_object_instance_id | Nej | X | Varchar(128) | |||
source_system | Nej | X | Varchar(64) | |||
data_controller | Nej | X | Varchar(64) | |||
owner | Nej | X | Varchar(64) | |||
clinical_process_interest_id | Nej | X | Varchar(128) | |||
creation_time | Nej | Timestamp | ||||
update_time | Ja | Timestamp | ||||
most_recent_content | Ja | Timestamp |
Förutom primärnyckeln som är id så finns ett sökindex med namnet engagement_search_index.
...
- Vid sökning av flera poster med hjälp av primärnyckeln används en "IN" sats och vissa databaser kan kan ha begränsningar med avseende på batch-storleken för denna typ av anrop
- Längden på några av kolumnerna kan möjligen överskrida någon begränsning
- Det kan finnas effektivare sätt att lagra informationen på, dvs. sökindex och tabelldata kan mycket väl slås ihop för denna typ av data. I MySQL fallet lagras tabell och index var för sig.
- Det kan finnas effektivare sätt att indexera på då den primära nyckeln passar utmärkt för ett "hash" index. MySQL och InnoDB är begränsat till B-Tree
...