Relaties modelleren
In dit artikel wordt het modelleringsproces besproken om u te helpen bij het ontwerpen van uw Azure Table Storage-oplossingen.
Het bouwen van domeinmodellen is een belangrijke stap in het ontwerp van complexe systemen. Normaal gesproken gebruikt u het modelleringsproces om entiteiten en de relaties tussen deze entiteiten te identificeren als een manier om het bedrijfsdomein te begrijpen en het ontwerp van uw systeem te informeren. In deze sectie wordt uitgelegd hoe u een aantal algemene relatietypen in domeinmodellen kunt vertalen naar ontwerpen voor de Tabelservice. Het toewijzingsproces van een logisch gegevensmodel aan een fysiek NoSQL-gegevensmodel verschilt van het model dat wordt gebruikt bij het ontwerpen van een relationele database. Bij het ontwerpen van relationele databases wordt doorgaans uitgegaan van een proces voor gegevensnormalisatie dat is geoptimaliseerd voor het minimaliseren van redundantie, en een declaratieve queryfunctie waarmee wordt geabstraheerd hoe de implementatie van de database werkt.
Eén-op-veel relaties
Een-op-veel-relaties tussen bedrijfsdomeinobjecten vinden vaak plaats: één afdeling heeft bijvoorbeeld veel werknemers. Er zijn verschillende manieren om een-op-veel-relaties in de Table-service te implementeren met voor- en nadelen die mogelijk relevant zijn voor het specifieke scenario.
Bekijk het voorbeeld van een grote multi-nationale/regionale onderneming met tienduizenden afdelingen en werknemersentiteiten waarbij elke afdeling veel werknemers en elke werknemer heeft als gekoppeld aan één specifieke afdeling. Eén benadering is het opslaan van afzonderlijke afdelings- en werknemersentiteiten, zoals deze:
In dit voorbeeld ziet u een impliciete een-op-veel-relatie tussen de typen op basis van de waarde PartitionKey . Elke afdeling kan veel werknemers hebben.
In dit voorbeeld ziet u ook een afdelingsentiteit en de bijbehorende werknemersentiteiten in dezelfde partitie. U kunt ervoor kiezen om verschillende partities, tabellen of zelfs opslagaccounts te gebruiken voor de verschillende entiteitstypen.
Een alternatieve benadering is het denormaliseren van uw gegevens en het opslaan van alleen werknemersentiteiten met gedenormaliseerde afdelingsgegevens, zoals wordt weergegeven in het volgende voorbeeld. In dit specifieke scenario is deze gedenormaliseerde benadering mogelijk niet het beste als u een vereiste hebt om de details van een afdelingsmanager te kunnen wijzigen, omdat u hiervoor elke werknemer in de afdeling moet bijwerken.
Zie het denormalisatiepatroon verderop in deze handleiding voor meer informatie.
De volgende tabel bevat een overzicht van de voor- en nadelen van elk van de hierboven beschreven benaderingen voor het opslaan van werknemers- en afdelingsentiteiten met een een-op-veel-relatie. U moet ook rekening houden met hoe vaak u verwacht verschillende bewerkingen uit te voeren: het kan acceptabel zijn om een ontwerp te hebben dat een dure bewerking omvat als die bewerking slechts zelden plaatsvindt.
| Methode | Voordelen | Nadelen |
|---|---|---|
| Afzonderlijke entiteitstypen, dezelfde partitie, dezelfde tabel |
|
|
| Afzonderlijke entiteitstypen, verschillende partities of tabellen of opslagaccounts |
|
|
| Denormaliseren in één entiteitstype |
|
|
*Zie Entiteitsgroeptransacties voor meer informatie
Hoe u kiest tussen deze opties en welke voor- en nadelen het belangrijkst zijn, is afhankelijk van uw specifieke toepassingsscenario's. Hoe vaak wijzigt u bijvoorbeeld afdelingsentiteiten; al uw werknemersquery's de aanvullende afdelingsinformatie nodig hebben; Hoe dicht ligt u bij de schaalbaarheidslimieten voor uw partities of uw opslagaccount?
Een-op-een-relaties
Domeinmodellen kunnen een-op-een-relaties tussen entiteiten bevatten. Als u een een-op-een-relatie in de Tabelservice moet implementeren, moet u ook kiezen hoe u de twee gerelateerde entiteiten koppelt wanneer u ze beide wilt ophalen. Deze koppeling kan impliciet zijn, op basis van een conventie in de sleutelwaarden of expliciet door een koppeling op te slaan in de vorm van PartitionKey- en RowKey-waarden in elke entiteit naar de gerelateerde entiteit. Zie de sectie Een-op-veel-relaties voor een discussie over het opslaan van de gerelateerde entiteiten in dezelfde partitie.
Er zijn ook implementatieoverwegingen die u kunnen leiden tot het implementeren van een-op-een-relaties in de Tabelservice:
- Grote entiteiten verwerken (zie Patroon grote entiteiten voor meer informatie).
- Toegangsbeheer implementeren (zie Toegang beheren met Shared Access Signatures) voor meer informatie.
Deelnemen aan de client
Hoewel er manieren zijn om relaties te modelleren in de Table-service, moet u niet vergeten dat de twee belangrijkste redenen voor het gebruik van de Table-service schaalbaarheid en prestaties zijn. Als u merkt dat u veel relaties modelleert die de prestaties en schaalbaarheid van uw oplossing in gevaar brengen, moet u zich afvragen of het nodig is om alle gegevensrelaties in uw tabelontwerp te bouwen. Mogelijk kunt u het ontwerp vereenvoudigen en de schaalbaarheid en prestaties van uw oplossing verbeteren als u uw clienttoepassing alle benodigde joins laat uitvoeren.
Als u bijvoorbeeld kleine tabellen hebt die gegevens bevatten die niet vaak worden gewijzigd, kunt u deze gegevens eenmaal ophalen en in de cache opslaan op de client. Dit kan voorkomen dat herhaalde retouren worden opgehaald om dezelfde gegevens op te halen. In de voorbeelden die we in deze handleiding hebben bekeken, is de set afdelingen in een kleine organisatie waarschijnlijk klein en veranderen ze zelden, waardoor het een goede kandidaat is voor gegevens die clienttoepassing eenmaal kan downloaden en de cache kan opslaan als opzoekgegevens.
Overnamerelaties
Als uw clienttoepassing gebruikmaakt van een set klassen die deel uitmaken van een overnamerelatie om bedrijfsentiteiten te vertegenwoordigen, kunt u deze entiteiten eenvoudig persistent maken in de Tabelservice. U hebt bijvoorbeeld de volgende set klassen die zijn gedefinieerd in uw clienttoepassing waarbij Person een abstracte klasse is.
U kunt exemplaren van de twee concrete klassen in de tabelservice persistent maken met behulp van één tabel Persoon met behulp van entiteiten die er als volgt uitzien:
Zie de sectie Werken met heterogene entiteitstypen verderop in deze handleiding voor meer informatie over het werken met meerdere entiteitstypen in dezelfde tabel in dezelfde tabel in clientcode. Dit bevat voorbeelden van het herkennen van het entiteitstype in clientcode.