Ma arvan, et ei peaks.
Kui andmebaasis oleksid tabelid:
Isik (isik_id, ...)
Primaarvõti (isik_id)
E_meil (e_meil_id, e_meil)
Primaarvõti (e_meil_id)
Alternatiivvõti (e_meil)
Isiku_meiliaadress (isik_id, e_meil_id)
Primaarvõti (isik_id, e_meil_id)
Välisvõti (isik_id) Viitab Isik (isik_id)
Välisvõti (e_meil_id) Viitab E_meil (e_meil_id)
, siis päring, mis seob isikuandmed meiliaadressidega, peab lugema kolme tabelit.
Eraldi meiliaadresside tabelil oleks mõtet, kui meiliaadressi kohta oleks vaja talletada veel andmeid - näiteks oleks tegemist põhiobjektiga, mille korral tuleb fikseerida selle seisund/staatus. Analoogiana võiks mõelda isiku nimele. Igal isikul on üks või rohkem nime komponenti (nt eesnimi, perenimi, isanimi) ning üks ja sama nimi võib kuuluda mitmele isikule. Lahendus, mille korral on eraldi tabel Isikunimi, kus oleksid näiteks registreeritud nimed nagu "Mari" ja "Maasikas", mida tuleks vahetabeli kaudu siduda tabeliga Isik, ei tundu mulle otstarbekas ja ma pole ka sellist lahendust kuskil kohanud.
Selle asemel võiks luua tabelid.
Isik (isik_id, ...)
Primaarvõti (isik_id)
Isiku_meiliaadress (isik_id, e_meil)
Primaarvõti (isik_id, e_meil)
Välisvõti (isik_id) Viitab Isik (isik_id)
Kui primaarvõtme kitsenduses on veerud just selles järjekorras, siis tekib andmebaasis automaatselt liitindeks, kus isik_id on esimene veerg. Sellisel juhul pole vaja luua välisvõtme toetuseks veerule isik_id eraldi indeksit. Ühtlasi tagab selline primaarvõti, et sama meiliaadressi ei saa sama isikuga korduvalt siduda.
Isiku_meiliaadress oleks antud juhul nn nõrk olemitüüp (weak entity type), mille eksemplari eksistents sõltub seotud tugeva olemitüüpi (strong entity type) Isik eksemplari olemasolust. Seega sobib Isik tabelile viitavale välisvõtmele ON DELETE CASCADE kompenseeriv tegevus. See on loogiline, sest meiliaadress on lisainfo isiku kohta ja kui kustub isik, siis peaks kustuma ka lisainfo.
Sellise kahe tabeliga lahenduse eelis ühe tabeliga lahenduse ees (meiliaadressid on salvestatud tabelis Isik kui massiivi väärtused, json objekt või XML objekt) on näiteks see, et lihtsam on jõustada reeglit, mille kohaselt samal isikul ei tohi olla sama meiliaadressi korduvalt.
Kui andmebaasis oleksid tabelid:
Isik (isik_id, ...)
Primaarvõti (isik_id)
E_meil (e_meil_id, e_meil)
Primaarvõti (e_meil_id)
Alternatiivvõti (e_meil)
Isiku_meiliaadress (isik_id, e_meil_id)
Primaarvõti (isik_id, e_meil_id)
Välisvõti (isik_id) Viitab Isik (isik_id)
Välisvõti (e_meil_id) Viitab E_meil (e_meil_id)
, siis päring, mis seob isikuandmed meiliaadressidega, peab lugema kolme tabelit.
Eraldi meiliaadresside tabelil oleks mõtet, kui meiliaadressi kohta oleks vaja talletada veel andmeid - näiteks oleks tegemist põhiobjektiga, mille korral tuleb fikseerida selle seisund/staatus. Analoogiana võiks mõelda isiku nimele. Igal isikul on üks või rohkem nime komponenti (nt eesnimi, perenimi, isanimi) ning üks ja sama nimi võib kuuluda mitmele isikule. Lahendus, mille korral on eraldi tabel Isikunimi, kus oleksid näiteks registreeritud nimed nagu "Mari" ja "Maasikas", mida tuleks vahetabeli kaudu siduda tabeliga Isik, ei tundu mulle otstarbekas ja ma pole ka sellist lahendust kuskil kohanud.
Selle asemel võiks luua tabelid.
Isik (isik_id, ...)
Primaarvõti (isik_id)
Isiku_meiliaadress (isik_id, e_meil)
Primaarvõti (isik_id, e_meil)
Välisvõti (isik_id) Viitab Isik (isik_id)
Kui primaarvõtme kitsenduses on veerud just selles järjekorras, siis tekib andmebaasis automaatselt liitindeks, kus isik_id on esimene veerg. Sellisel juhul pole vaja luua välisvõtme toetuseks veerule isik_id eraldi indeksit. Ühtlasi tagab selline primaarvõti, et sama meiliaadressi ei saa sama isikuga korduvalt siduda.
Isiku_meiliaadress oleks antud juhul nn nõrk olemitüüp (weak entity type), mille eksemplari eksistents sõltub seotud tugeva olemitüüpi (strong entity type) Isik eksemplari olemasolust. Seega sobib Isik tabelile viitavale välisvõtmele ON DELETE CASCADE kompenseeriv tegevus. See on loogiline, sest meiliaadress on lisainfo isiku kohta ja kui kustub isik, siis peaks kustuma ka lisainfo.
Sellise kahe tabeliga lahenduse eelis ühe tabeliga lahenduse ees (meiliaadressid on salvestatud tabelis Isik kui massiivi väärtused, json objekt või XML objekt) on näiteks see, et lihtsam on jõustada reeglit, mille kohaselt samal isikul ei tohi olla sama meiliaadressi korduvalt.
Hinda postitust:
Keskmine hinne : Pole veel hinnanguid!