Tato otázka ukazuje, že úplně nerozumíte vztahům entit (žádná hrubost není zamýšlena). Z nichž níže jsou čtyři (technicky pouze 3) typy:
One to One One to Many Many to One Many to Many
Jedna ku jedné (1:1): V tomto případě byla tabulka rozdělena na dvě části za účelem dodržení normalizace, nebo obvykleji principu otevřeno a zavřeno.
Normalizace soulad:Můžete mít obchodní pravidlo, že každý zákazník má pouze jeden účet. Technicky byste v tomto případě mohli říci, že zákazník a účet mohou být všichni ve stejné tabulce, ale to porušuje pravidla normalizace, takže je rozdělíte a uděláte 1:1.
Princip otevření-zavření shoda:Tabulka zákazníků, může mít ID, jméno a příjmení a adresu. Později se někdo rozhodne přidat datum narození a s ním možnost vypočítat věk spolu s hromadou dalších tolik potřebných polí. Toto je příliš zjednodušený příklad jedna ku jedné, ale jeho hlavním využitím je rozšíření databáze bez porušení stávajícího kódu. Mnoho napsaného kódu (bohužel) je pevně spojeno s databází, takže změny ve struktuře tabulky kód naruší. Přidání 1:1, jako je tento, rozšíří tabulku tak, aby splňovala nové požadavky bez úpravy původního kódu, což umožní, aby starý kód nadále fungoval normálně a nový kód mohl využívat nové funkce db.
Nevýhodou normalizace a rozšiřování tabulek pomocí vztahů 1:1 tímto způsobem je výkon. Na vysoce používaných systémech je často prvním cílem zvýšení výkonu databáze denormalizace a kombinování takových tabulek do jedné tabulky a optimalizace indexů, čímž se odstraní potřeba používat spojení a číst z více tabulek. Normalizace / De-normalizace není dobrá ani špatná věc, protože závisí na potřebách systému. Většina systémů obvykle začíná normalizovanou změnou zpět, když je potřeba, ale tato změna musí být provedena velmi opatrně, jak bylo zmíněno, pokud je kód pevně spojen se strukturou DB, téměř určitě způsobí selhání systému. tj. když zkombinujete 2 tabulky, jedna přestane existovat, veškerý kód, který obsahuje tuto nyní neexistující tabulku, selže, dokud nebude upraven (z hlediska db, představte si připojení vztahů k jakékoli z tabulek v 1:1, když tyto tabulky odstraníte , to narušuje vztahy, a tak se musí struktura výrazně upravit, aby se to kompenzovalo. Bohužel, takové špatné návrhy jsou ve většině případů mnohem snáze rozpoznatelné ve světě DB než ve světě softwaru a obvykle si nevšimnete, že se něco pokazilo v kódu, dokud se to všechno nerozpadne), pokud není systém správně navržen s oddělením obav na mysli.
Je to nejbližší věc, kterou se můžete dostat k dědičnosti v objektově orientovaném programování. Ale není to úplně totéž.
Jeden k mnoha (1:M) / Mnoho k jednomu (M:1): Tyto dva vztahy (proč se tedy ze 4 stávají 3) jsou nejoblíbenějšími typy vztahů. Oba jsou stejného typu vztahu, jediné, co se mění, je váš úhel pohledu. Příklad Zákazník má mnoho telefonních čísel, případně mnoho telefonních čísel může patřit zákazníkovi.
V objektově orientovaném programování by to bylo považováno za kompozici. Není to dědictví, ale říkáte, že jedna položka se skládá z mnoha částí. To je obvykle reprezentováno poli / seznamy / kolekcemi atd. uvnitř tříd, na rozdíl od struktury dědičnosti.
Mnoho mnoha (M:M): Tento typ vztahu se současnou technologií je nemožný. Z tohoto důvodu jej musíme rozdělit na dva, jeden až mnoho vztahů s tabulkou „asociace“, která je spojuje. Mnohostranné vztahy dvou jedna k mnoha jsou vždy v tabulce přidružení/propojení.
Například ten, kdo řekl, že potřebujete mnoho k mnoha, má pravdu. Protože dva k mnoha je ve skutečnosti vztah mnoho (což znamená více než jeden) k mnoha. To je jediný způsob, jak zprovoznit váš systém. Pokud nemáte v úmyslu zkoumat pole relační kalkul najít nějaký nový typ vztahu, který by to umožňoval.
Také pro takové vztahy (m2m) máte dvě možnosti, buď vytvořit složený klíč v tabulce linkeru, aby se kombinace polí stala jedinečnou položkou (pokud máte zájem o optimalizaci db, je to pomalejší volba, ale zabírá méně místa). Alternativně můžete vytvořit třetí pole s automaticky generovaným sloupcem id a učinit z něj primární klíč (pro optimalizaci databáze je to rychlejší volba, ale zabere více místa).
Ve vašem příkladu konkrétně výše...
To by bylo mnoho nebo mnoho vztahů s tabulkou telefonních čísel jako spojovací tabulkou mezi společnostmi a uživateli. Jak bylo vysvětleno, abyste zajistili, že se žádné telefonní číslo nebude opakovat, jednoduše jej nastavíte jako primární klíč nebo použijete jiný primární klíč a pole telefonního čísla nastavíte na jedinečné.
U takových otázek opravdu záleží na tom, jak je formulujete. Co způsobuje, že jste v tom zmatení a jak tento zmatek překonáte, abyste viděli řešení, je jednoduché. Přeformulujte problém následovně. Začněte tím, že se zeptáte, zda je to jedna k jedné, pokud je odpověď ne, pokračujte. Další zeptejte se je to jedna k mnoha, pokud je odpověď ne, pokračujte. Jedinou zbývající možností je mnoho. Buďte však opatrní a ujistěte se, že jste pečlivě zvážili první 2 otázky, než budete pokračovat. Mnoho nezkušených databázových lidí často příliš komplikuje problémy tím, že definují jeden k mnoha jako mnoho k mnoha. Ještě jednou, zdaleka nejoblíbenější typ vztahu je jeden k mnoha (řekl bych 90 %), přičemž mnoho k mnoha a jeden k jednomu rozděluje zbývajících 10 % 7/3. Ale tato čísla jsou jen můj osobní pohled, takže je neuvádějte jako průmyslové standardní statistiky. Mým cílem je ujistit se, že to rozhodně není jedna k mnoha, než si zvolím mnoho k mnoha. Stojí to za to úsilí navíc.
Chcete-li tedy nyní najít spojovací tabulku mezi těmito dvěma, rozhodněte se, které dvě jsou vaše hlavní tabulky a která pole je třeba mezi nimi sdílet. V tomto případě musí firemní i uživatelské stoly sdílet telefon. Proto musíte vytvořit nový telefonní stůl jako linker.
Varovný alarm nedorozumění by se měl objevit, jakmile se rozhodnete, že žádný z těchto 3 pro vás nefunguje. To by vám mělo stačit k tomu, abyste řekli, že otázku vztahu jednoduše neformulujete správně. Postupem času se v tom budete zlepšovat, ale je to základní dovednost a opravdu byste si ji měli osvojit co nejdříve, abyste si ji osvojili.
Samozřejmě můžete také přejít do objektově orientované databáze, která umožní řadu dalších vztahů nazývaných "hierarchacal" vztahy. To je skvělé, pokud uvažujete o tom, že se také stanete programátorem. Ale nedoporučoval bych to, protože vás z toho bude bolet hlava, když začnete hledat způsoby, jak kombinovat různé typy vztahů. Obzvláště vzhledem k tomu, že toho není mnoho potřeba, protože téměř všechny databáze na světě se skládají pouze z těchto 3 typů vztahů, pokud se nejedná o něco super duper speciálního.
Doufám, že to byla rozumná odpověď. Děkujeme, že jste si našli čas na přečtení.