Wat is een exclusieve boog in de database en waarom is het ' slecht?

Voor zover ik het lang geleden begreep, in een exclusieve arc a table bevat een aantal kolommen die refererende sleutels zijn voor andere tabellen, maar er kan er maar één tegelijk worden ingesteld (vanwege een logische beperking op het domein die volgt uit de echte wereld). Aangezien deze regel niet kan worden afgedwongen in de database, kan een beschadigd record worden aangemaakt als meer dan één van deze externe sleutels een waarde heeft.

Ik zal een voorbeeld geven. Beschouw een toepassing waarbij een bedrijf de vrachtwagens die het gebruikt om goederen af te leveren. Een vrachtwagen kan maar op een van de drie plaatsen tegelijk zijn: het kan bij een medewerker zijn, het kan in een parkeergarage staan of het kan in een onderhoudswerkplaats zijn. Dit kan worden gemodelleerd door een Truck-table te hebben met employeeId, parkingGarageId en maintenanceShopId, verwijzend naar de Employee, ParkingGarage en MaintenanceShop-tabellen. Er is geen manier om de regel af te dwingen dat slechts één van deze velden wordt ingevuld op het niveau van de database. Onjuiste code of iemand met directe toegang tot de database zou een record kunnen invoegen waarvan twee of drie velden zijn ingevuld, wat neerkomt op gegevensbeschadiging in de database.

Opmerkingen

• De drie mogelijke vrachtwagenlocaties zijn subklassen van een superklasse, " vrachtwagenlocatie ". Er zijn veel gevallen waarin subklassen elkaar uitsluiten. De uitdaging wordt hoe klassen en subklassen in relationele tabellen moeten worden gemodelleerd.
• Ik ben het ermee eens dat er gevallen zijn waarin het gebruik van dit ontwerp gerechtvaardigd is. Ik kan echter ook instemmen met de originele post dat dit patroon VEEL meer wordt gebruikt dan zou moeten. Het heeft ook enkele zeer grote nadelen …
• Kan er geen controlevoorwaarde worden gebruikt? Bijvoorbeeld alter table mytable add constraint myconstraint check ((col1 is not null and col2 is null and col3 is null) or (col1 is null and col2 is not null and col3 is null) or (col1 is null and col2 is null and col3 is not null)). Ik hou niet van ' exclusieve bogen, maar ze kunnen worden afgedwongen met een controlebeperking. Natuurlijk moet de FK-beperking ook aanwezig zijn.
• Vandaar de " complexe controlebeperkingen niettegenstaande " uit de post hierboven geciteerd. Je zou in staat kunnen zijn om echt geavanceerde validatie uit te voeren met controlebeperkingen of zelfs triggers, die het niet ' tot een goed idee of een teken van goed ontwerp maken. Stel je voor dat je controlebeperkingen uitvoert op exclusieve bogen met vier of vijf kolommen … Bovendien ben ik ' er vrij zeker van dat niet alle database-engines ondersteuning van de CHECK-beperking . MySQL stelt expliciet in de documenten dat CHECK-clausules worden geparseerd, maar genegeerd …
• Deze bron beveelt exclusieve arc aan. Gedachten?

Er is niets kwaads aan exclusieve bogen. Dwing gewoon de bijbehorende bedrijfsregel af met behulp van een controlevoorwaarde. De meeste grote databasebeheersystemen ondersteunen controlebeperkingen (Oracle, SQL Server, PostgreSQL). Als u een datamodelleringstool gebruikt, is de kans groot dat uw tool automatisch de code genereert om de controlebeperking te implementeren.

De exclusieve boog is erg handig in het conceptuele of logische ontwerp. Het betekent niet dat je die manier moet implementeren. In het eerdere voorbeeld kan de ontwerper besluiten om het ontwerp met drie tafels te implementeren. Een voor parkeren locatie, een voor de medewerker en een voor de onderhoudswerkplaats.