...
| Kolumnnamn | Null | Primär- nyckel | Del av logisk- nyckel | Typ och Längd |
|---|---|---|---|---|
| id | Nej | X | Varchar(64) | |
registered_resident_ididentification | Nej | X | Varchar(32) | |
service_domain | Nej | X | Varchar(255) | |
categorization | Nej | X | Varchar(255) | |
logical_address | Nej | X | Varchar(64) | |
business_object_instance_ididentifier | 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 |
...
Observera att användningen av en teknisk primärnyckel inte förändrar det faktum att man inte under några omständigheter kan ändra på någon del av verksamhetsnyckeln, dvs. utifrån detta perspektiv är det exakt samma hantering som om verksamhetsnyckeln hade används som primärnyckel. Därför har varje fält som ingår i verksamhetsnyckeln markerats med en JPA indikator om att fältet ifråga inte ska uppdateras.
Tidstämpel
Det finns som sagt 3 fält av typen tidstämpel, och samtliga förväntas hanteras till fullo av verksamhetslagret, dvs. persistenslagret sätter eller ändrar för närvarande inte dessa tidstämplar. Däremot säkerställs att creation_time endast sätts första gången en post skapas i databasen, dvs. den uppdateras inte efter detta.
Sökningar
För sökningar används springs JPA repository interface, där sökningar definieras antingen med namnkonvention eller med SQL (JPQL) satser.
Transaktioner
Precis som förespråkas i tjänstekontraktsbeskrivningen så krävs ingen särskild transaktionskonsistens när man läser data, dvs. man tillåter så kallade "dirty reads" om nu den underliggande databasen tillåter detta. Självfallet måste alla skrivningar hanteras på ett atomärt och konsistent sätt, även om man tillåter sk. "dirty reads".
Portering
...
av databas
Nuvarande implementation har endast verifierats med MySQL 5 databas och det då med InnoDB som transaktionsmotor (engine). Det finns ett antal punkter som man bör reflektera över när det gäller portering till andra databaser:
- 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
...
- 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 i et "hash" index. MySQL och InnoDB är begränsat till B-Tree