Den här frågan visar att du inte helt förstår entitetsrelationer (ingen elakhet avsedd). Av vilka det finns fyra (tekniskt sett endast 3) typer nedan:
One to One One to Many Many to One Many to Many
En till en (1:1): I det här fallet har en tabell delats upp i två delar i syfte att följa normaliseringen, eller mer vanligtvis den öppna stängda principen.
Normalisering efterlevnad:Du kanske har en affärsregel att varje kund bara har ett konto. Tekniskt sett kan du i det här fallet säga att kund och konto alla kan vara i samma tabell, men detta bryter mot reglerna för normalisering, så du delar upp dem och gör en 1:1.
Öppna-Stäng-principen efterlevnad:En kundtabell, kan ha id, för- och efternamn och adress. Senare bestämmer sig någon för att lägga till ett födelsedatum och med det möjligheten att beräkna ålder tillsammans med en massa andra välbehövliga fält. Detta är ett alltför förenklat exempel på en till en, men du får den huvudsakliga användningen för det är att utöka din databas utan att bryta befintlig kod. Mycket kod skriven (tyvärr) är tätt kopplad till databasen så förändringar i strukturen i en tabell kommer att bryta koden. Om du lägger till en 1:1 som denna kommer att utöka tabellen för att möta nya krav utan att ändra den ursprungliga, vilket gör att gammal kod fortsätter att fungera normalt och ny kod kan använda de nya db-funktionerna.
Nackdelen med att normalisera och utöka tabeller med 1:1-relationer på detta sätt är prestanda. Ofta på hårt använda system är det första målet för att öka databasprestanda att denormalisera och kombinera sådana tabeller till en enda tabell, och optimera indexen vilket tar bort behovet av att använda joins och läsa från flera tabeller. Normalisering / avnormalisering är varken en bra eller dålig sak, eftersom det beror på systemets behov. De flesta system börjar vanligtvis normaliserat byte tillbaka när det behövs, men denna förändring måste göras mycket noggrant som nämnts, om koden är tätt kopplad till DB-strukturen kommer det nästan definitivt att leda till att systemet misslyckas. d.v.s. När du kombinerar 2 tabeller, upphör en att existera, all kod som inkluderar den nu icke-existerande tabellen misslyckas tills den modifieras (i db-termer, tänk dig att koppla relationer till någon av tabellerna i 1:1, när du tar bort dessa tabeller , detta bryter relationerna, och därför måste strukturen modifieras kraftigt för att kompensera. Tyvärr är sådana dåliga designs mycket lättare att upptäcka i DB-världen än i mjukvaruvärlden i de flesta fall och du brukar inte märka att något gick fel i kod tills allt faller sönder) om inte systemet är korrekt designat med separation of care i åtanke.
Det är det närmaste man kan komma arv i objektorienterad programmering. Men det är inte riktigt samma sak.
En till många (1:M) / Många till en (M:1): Dessa två relationer (därav varför 4 blir 3), är de mest populära relationstyperna. De är båda av samma typ av relation, det enda som förändras är din synvinkel. Ett exempel En kund har många telefonnummer, eller alternativt kan många telefonnummer tillhöra en kund.
I objektorienterad programmering skulle detta betraktas som komposition. Det är inte arv, men du säger att ett föremål består av många delar. Detta representeras vanligtvis med arrayer / listor / samlingar etc. inuti klasser i motsats till en arvsstruktur.
Många till många (M:M): Denna typ av relation med nuvarande teknik är omöjlig. Av denna anledning måste vi dela upp det i två en till många relationer med en "associationstabell" som förenar dem. Den många sidan av de två en till många relationer finns alltid på associations-/länktabellen.
Till ditt exempel har personen som sa att du behöver många till många rätt. Eftersom en två till många är faktiskt en många (vilket betyder mer än en) till många relation. Detta är det enda sättet du skulle få ditt system att fungera. Såvida du inte tänker forska inom området relationskalkyl att hitta någon ny typ av relation som skulle tillåta detta.
Även för sådana relationer (m2m) har du två val, antingen skapa en sammansatt nyckel i länktabellen så att kombinationen av fält blir en unik post (om du är intresserad av db-optimering är detta det långsammare valet, men tar mindre plats). Alternativt skapar du ett tredje fält med en automatiskt genererad id-kolumn och gör den till primärnyckeln (för db-optimering är detta det snabbare valet, men det tar mer plats).
I ditt exempel ovan...
Detta skulle vara ett många till många förhållande med telefonnummertabellen som länktabellen mellan företag och användare. Som förklarat, för att säkerställa att inget telefonnummer upprepas, ställer du bara in det som primärnyckel eller använder en annan primärnyckel och ställer in telefonnummerfältet på unikt.
För den typen av frågor beror det verkligen på hur du formulerar dem. Vad som får dig att bli förvirrad över detta, och hur du övervinner denna förvirring för att se lösningen är enkelt. Omformulera problemet enligt följande. Börja med att fråga är det en till en, om svaret är nej, gå vidare. Nästa fråga är det en till många, om svaret inte är gå vidare. Det enda andra alternativet som återstår är många till många. Var dock försiktig, se till att du har övervägt de två första frågorna noggrant innan du går vidare. Många oerfarna databasmänniskor komplicerar ofta problem genom att definiera en till många som många till många. Återigen är den överlägset mest populära typen av relation en till många (jag skulle säga 90 %) med många till många och en till en som delar de återstående 10 % 7/3 respektive. Men de siffrorna är bara mitt personliga perspektiv, så citera dem inte som industristandardstatistik. Min poäng är att vara extra säker på att det definitivt inte är en till många innan jag väljer många till många. Det är värt den extra ansträngningen.
Så nu för att hitta länktabellen mellan de två, bestäm vilka två som är dina huvudtabeller och vilka fält som behöver delas mellan dem. I det här fallet måste både företags- och användartabeller dela telefonen. Därför måste du skapa en ny telefontabell som länk.
Varningslarmet om missförstånd bör visas så snart du bestämmer dig för att ingen av de 3 fungerar för dig. Detta borde vara tillräckligt för att berätta att du helt enkelt inte formulerar relationsfrågan korrekt. Du kommer att bli bättre på det med tiden, men det är en viktig färdighet och bör verkligen bemästras så snart som möjligt för din egen förnuft.
Naturligtvis kan du också gå till en objektorienterad databas som tillåter en rad andra relationer som kallas "hierarkakala" relationer. Det är bra om du funderar på att bli programmerare också. Men jag skulle inte rekommendera detta eftersom det kommer att göra ont i huvudet när du börjar hitta sätt att kombinera de olika typerna av relationer. Speciellt med tanke på att det inte finns så mycket behov eftersom nästan alla databaser i världen bara består av dessa tre typer av relationer såvida de inte är något superduper speciellt.
Hoppas detta var ett rimligt svar. Tack för att du tog dig tid att läsa den.