Deze vraag laat zien dat je de relaties tussen entiteiten niet volledig begrijpt (geen onbeschoftheid bedoeld). Waarvan er vier (technisch slechts 3) soorten zijn hieronder:
One to One One to Many Many to One Many to Many
Eén op één (1:1): In dit geval is een tabel opgedeeld in twee delen om te voldoen aan normalisatie, of meer gebruikelijk het open-gesloten-principe.
Normalisatie naleving:u heeft mogelijk een bedrijfsregel dat elke klant slechts één account heeft. Technisch gezien zou je in dit geval kunnen zeggen dat klant en account zich allemaal in dezelfde tabel kunnen bevinden, maar dit breekt de regels van normalisatie, dus je splitst ze en maakt een 1:1.
Open-Close-principe naleving:een klantentabel kan een id, voor- en achternaam en adres bevatten. Later besluit iemand een geboortedatum toe te voegen en daarmee de mogelijkheid om leeftijd te berekenen, samen met een heleboel andere broodnodige velden. Dit is een te vereenvoudigd voorbeeld van één op één, maar het belangrijkste gebruik ervan is om uw database uit te breiden zonder bestaande code te breken. Veel geschreven code is (helaas) nauw gekoppeld aan de database, dus veranderingen in de structuur van een tabel zullen de code breken. Door op deze manier een 1:1 toe te voegen, wordt de tabel uitgebreid om aan nieuwe vereisten te voldoen zonder de originele te wijzigen, waardoor de oude code normaal kan blijven functioneren en de nieuwe code gebruik kan maken van de nieuwe db-functies.
Het nadeel van het normaliseren en uitbreiden van tabellen met behulp van 1:1 relaties op deze manier is de prestatie. Op intensief gebruikte systemen is het eerste doel om de databaseprestaties te verbeteren, het de-normaliseren en combineren van dergelijke tabellen in een enkele tabel, en het optimaliseren van de indexen, waardoor het niet meer nodig is om joins te gebruiken en uit meerdere tabellen te lezen. Normalisatie / De-normalisatie is noch een goede noch een slechte zaak, omdat het afhangt van de behoeften van het systeem. De meeste systemen beginnen gewoonlijk met genormaliseerd terugschakelen wanneer dat nodig is, maar deze wijziging moet zeer zorgvuldig worden gedaan, zoals vermeld, als code nauw is gekoppeld aan de DB-structuur, zal dit vrijwel zeker tot gevolg hebben dat het systeem faalt. d.w.z. wanneer u 2 tabellen combineert, houdt er één op te bestaan, alle code die die nu niet-bestaande tabel bevat, mislukt totdat deze wordt gewijzigd (in db-termen, stel u voor dat u relaties verbindt met een van de tabellen in de 1:1, wanneer u die tabellen verwijdert , dit verbreekt de relaties, en dus moet de structuur sterk worden aangepast om te compenseren. Helaas zijn dergelijke slechte ontwerpen in de meeste gevallen veel gemakkelijker te herkennen in de DB-wereld dan in de softwarewereld en merk je meestal niet dat er iets mis is gegaan in code totdat het allemaal uit elkaar valt), tenzij het systeem goed is ontworpen met scheiding van zorgen in gedachten.
Het komt het dichtst in de buurt van overerving in objectgeoriënteerd programmeren. Maar het is niet helemaal hetzelfde.
Eén op veel (1:M) / Veel op één (M:1): Deze twee relaties (vandaar waarom 4 worden 3), zijn de meest populaire relatietypes. Ze zijn allebei hetzelfde type relatie, het enige dat verandert is jouw standpunt. Een voorbeeld Een klant heeft veel telefoonnummers, of er kunnen veel telefoonnummers bij een klant horen.
Bij objectgeoriënteerd programmeren zou dit als compositie worden beschouwd. Het is geen erfenis, maar u zegt dat één item uit vele delen bestaat. Dit wordt meestal weergegeven met arrays / lijsten / verzamelingen enz. binnen klassen in tegenstelling tot een overervingsstructuur.
Veel tot veel (M:M): Een dergelijke relatie met de huidige technologie is onmogelijk. Om deze reden moeten we het opsplitsen in twee een-op-veel-relaties met een "associatie"-tabel die hen verbindt. De vele kant van de twee één-op-veel relaties staat altijd op de associatie-/linktabel.
Voor jouw voorbeeld, de persoon die zei dat je veel op veel nodig hebt, heeft gelijk. Omdat een twee-op-veel-relatie in feite een veel (dat wil zeggen meer dan één) op veel-relatie is. Dit is de enige manier om uw systeem te laten werken. Tenzij u van plan bent onderzoek te doen op het gebied van relationele calculus om een nieuw type relatie te vinden die dit mogelijk maakt.
Ook voor dergelijke relaties (m2m) heb je twee keuzes, ofwel maak je een samengestelde sleutel in de linkertabel zodat de combinatie van velden een uniek item wordt (als je geïnteresseerd bent in db-optimalisatie is dit de langzamere keuze, maar neemt minder ruimte in beslag). Als alternatief maakt u een derde veld met een automatisch gegenereerde id-kolom en maakt u dat de primaire sleutel (voor db-optimalisatie is dit de snellere keuze, maar neemt meer ruimte in beslag).
In uw voorbeeld specifiek hierboven...
Dit zou een veel-op-veel-relatie zijn met de telefoonnummertabel als de linkertabel tussen bedrijven en gebruikers. Zoals uitgelegd, om ervoor te zorgen dat geen telefoonnummer wordt herhaald, stelt u het gewoon in als de primaire sleutel of gebruikt u een andere primaire sleutel en stelt u het telefoonnummerveld in op uniek.
Voor dat soort vragen ligt het er echt aan hoe je ze formuleert. Wat ervoor zorgt dat je hierover in de war raakt, en hoe je deze verwarring overwint om de oplossing te zien, is eenvoudig. Formuleer het probleem als volgt. Begin met te vragen of het één op één is, als het antwoord nee is, ga dan verder. Volgende vraag is het een één voor velen, als het antwoord nee is, ga verder. De enige andere optie die overblijft is veel tot veel. Wees echter voorzichtig, zorg ervoor dat u de eerste 2 vragen zorgvuldig hebt overwogen voordat u verder gaat. Veel onervaren databasemensen maken problemen vaak te ingewikkeld door één tot veel te definiëren. Nogmaals, verreweg het meest populaire type relatie is een op veel (ik zou zeggen 90%) waarbij de veel op veel en een op een de resterende 10% 7/3 respectievelijk verdelen. Maar die cijfers zijn slechts mijn persoonlijke perspectief, dus ga ze niet citeren als industriestandaardstatistieken. Mijn punt is om er extra zeker van te zijn dat het zeker niet een te veel is voordat ik veel op veel kies. Het is de extra inspanning waard.
Dus om nu de linkertabel tussen de twee te vinden, beslis welke twee uw hoofdtabellen zijn en welke velden tussen hen moeten worden gedeeld. In dit geval moeten zowel de bedrijfs- als de gebruikerstafel de telefoon delen. Daarom moet je een nieuwe telefoontafel maken als linker.
Het waarschuwingsalarm voor misverstanden zou moeten verschijnen zodra u besluit dat geen van de 3 voor u werkt. Dit zou voldoende moeten zijn om u te vertellen dat u de relatievraag gewoon niet correct formuleert. Je zult er met het verstrijken van de tijd beter in worden, maar het is een essentiële vaardigheid die je zo snel mogelijk onder de knie moet krijgen voor je eigen geestelijke gezondheid.
Natuurlijk kunt u ook naar een objectgeoriënteerde database gaan die een reeks andere relaties mogelijk maakt die "Hiërarchische" relaties worden genoemd. Dat is geweldig als je erover denkt om ook programmeur te worden. Maar ik zou dit niet aanraden, omdat je er hoofdpijn van krijgt als je manieren begint te vinden om de verschillende soorten relaties te combineren. Vooral gezien het feit dat er niet veel nodig is, aangezien bijna alle databases ter wereld uit slechts die 3 soorten relaties bestaan, tenzij ze iets superduper speciaals zijn.
Hoop dat dit een redelijk antwoord was. Bedankt dat je de tijd hebt genomen om het te lezen.