Mikä on eksklusiivinen kaari tietokannassa ja miksi se ' on paha?

Sikäli kuin ymmärsin sen kauan sitten, yksinoikeudella kaari taulukko sisältää useita sarakkeita, jotka ovat vieraita avaimia muille taulukoille, mutta vain yksi näistä voidaan asettaa kerrallaan (johtuen todellisesta maailmasta seuraavista toimialueen loogisista rajoituksista). Koska tätä sääntöä ei voida panna täytäntöön tietokannassa, voidaan luoda vioittunut tietue, jossa useammalla kuin yhdellä näistä ulkomaisista avaimista on arvo.

Annan esimerkin. Tarkastellaan sovellusta, jossa yritys seuraa kuorma-autot, joita se käyttää tavaroiden toimittamiseen. Kuorma-auto voi olla vain yhdessä kolmesta paikasta samanaikaisesti: se voi olla työntekijän kanssa, se voi olla pysäköintihallissa tai se voi olla huoltoliikkeessä. ottamalla kuorma-taulukko, jossa on työntekijäId, parkingGarageId ja maintenanceShopId, viitaten Employee, ParkingGarage ja MaintenanceShop-taulukoihin. Ei ole mitään keinoa panna täytäntöön sääntöä, että vain yksi näistä kentistä täytetään tietokannan tasolla. joku, jolla on suora pääsy tietokantaan, voi lisätä tietueen, jossa on kaksi tai kolme kenttää, mikä tarkoittaa tietojen vioittumista tietokantaan.

Kommentit

• Kolme mahdollista kuorma-autopaikkaa ovat superluokan alaluokkia, " kuorma-auton sijainti ". On monia tapauksia, joissa alaluokat sulkevat toisensa pois. Haasteena on luokkien ja alaluokkien mallintaminen relaatiotaulukoissa.
• Olen samaa mieltä siitä, että joissakin tapauksissa tämän suunnittelun käyttö on perusteltua. Voin kuitenkin myös olla samaa mieltä alkuperäisen viestin kanssa siitä, että tätä mallia käytetään paljon enemmän kuin sen pitäisi. Sillä on myös erittäin suuria haittoja …
• Eikö tarkistusrajoitusta voida käyttää? Esimerkiksi 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)). En ' pidä yksinoikeudellisista kaarista, mutta ne voidaan valvoa tarkistusrajoituksella. Tietysti myös FK-rajoituksen on oltava läsnä.
• Tästä syystä " -kompleksin tarkistusrajoitukset ovat huolimatta viestin " -kohdasta. lainattu edellä. Saatat pystyä tekemään todella hienostuneen tarkistuksen tarkistusrajoituksilla tai heckillä, jopa laukaisuilla, jotka eivät tee ' t siitä hyvää ideaa tai hyvän suunnittelun tunnusta. Kuvittele, että teet tarkistusrajoituksia yksinoikeuskaareille, joissa on neljä tai viisi saraketta … Olen myös varma, että eivät kaikki tietokantamoottorit tukea TARKISTA-rajoitusta . MySQL toteaa asiakirjoissa nimenomaisesti, että TARKISTA-lausekkeet jäsennetään, mutta jätetään huomiotta …
• Tämä lähde suosittelee yksinoikeuskaarta. Ajatuksia?

Yksinoikeuskaarissa ei ole mitään pahaa. Täytä vastaava liiketoimintasääntö yksinkertaisesti tarkistusrajoituksella. Useimmat suuret tietokannan hallintajärjestelmät tukevat tarkistusrajoituksia (Oracle, SQL Server, PostgreSQL). Jos käytät tietomallinnustyökalua, on hyvät mahdollisuudet, että työkalusi luo koodin automaattisesti tarkistusrajoituksen toteuttamiseksi.