Този въпрос показва, че не разбирате напълно връзките на субектите (без предназначение за грубост). От които има четири (технически само 3) типа по-долу:
One to One One to Many Many to One Many to Many
Едно към едно (1:1): В този случай таблица е разделена на две части с цел спазване на нормализирането или по-често отворения затворен принцип.
Нормализация съответствие:Може да имате бизнес правило, че всеки клиент има само един акаунт. Технически в този случай бихте могли да кажете, че клиентът и акаунтът може да са в една и съща таблица, но това нарушава правилата за нормализиране, така че ги разделяте и правите 1:1.
Принцип отваряне-затваряне съответствие:клиентска таблица, може да има идентификатор, собствени и фамилни имена и адрес. По-късно някой решава да добави дата на раждане и с нея възможността за изчисляване на възрастта заедно с куп други много необходими полета. Това е твърде опростен пример за едно към едно, но основното му използване е да разширите вашата база данни, без да нарушавате съществуващия код. Много написан код (за съжаление) е тясно свързан с базата данни, така че промените в структурата на таблицата ще нарушат кода. Добавянето на 1:1 като това ще разшири таблицата, за да отговори на новите изисквания, без да променя оригиналния, като по този начин ще позволи на стария код да продължи да функционира нормално, а на новия код да използва новите функции на db.
Недостатъкът на нормализирането и разширяването на таблици, използващи релации 1:1 по този начин, е производителността. Често пъти при силно използвани системи първата цел за повишаване на производителността на базата данни е денормализирането и комбинирането на такива таблици в една таблица и оптимизирането на индексите, като по този начин се премахва необходимостта от използване на обединения и четене от множество таблици. Нормализирането / Денормализирането не е нито добро, нито лошо нещо, тъй като зависи от нуждите на системата. Повечето системи обикновено започват нормализирана промяна обратно, когато е необходимо, но тази промяна трябва да се направи много внимателно, както беше споменато, ако кодът е тясно свързан със структурата на DB, това почти определено ще доведе до отказ на системата. т.е., когато комбинирате 2 таблици, едната престава да съществува, целият код, който включва тази сега несъществуваща таблица, се проваля, докато не бъде променена (в термини на db, представете си свързване на релации с която и да е от таблиците в 1:1, когато премахнете тези таблици , това нарушава връзките и затова структурата трябва да бъде значително променена, за да компенсира. За съжаление, такива лоши дизайни са много по-лесни за забелязване в света на DB, отколкото в света на софтуера в повечето случаи и обикновено не забелязвате, че нещо се е объркало в код, докато всичко се разпадне), освен ако системата не е проектирана правилно с разделяне на притесненията предвид.
Това е най-близкото нещо, което можете да стигнете до наследяване при обектно-ориентирано програмиране. Но не е съвсем същото.
Едно към много (1:M) / Много към едно (M:1): Тези две връзки (следователно защо 4 стават 3) са най-популярните типове взаимоотношения. И двамата са от един и същи тип връзка, единственото нещо, което се променя, е вашата гледна точка. Пример Клиент има много телефонни номера или алтернативно много телефонни номера могат да принадлежат на клиент.
В обектно ориентираното програмиране това би се считало за композиция. Не е наследство, но казвате, че един елемент се състои от много части. Това обикновено се представя с масиви/списъци/колекции и т.н. вътре в класовете, за разлика от структурата на наследяване.
Много към много (М:М): Този тип връзка със съвременните технологии е невъзможна. Поради тази причина трябва да го разделим на две релации от един до много, като към тях се присъединява таблица за "асоцииране". Многостранната страна на двете връзки едно към много винаги е в таблицата за асоцииране/връзка.
За вашия пример човекът, който каза, че имате нужда от много към много, е прав. Защото две към много всъщност е връзка много (което означава повече от едно) към много. Това е единственият начин да накарате системата си да работи. Освен ако не възнамерявате да изследвате областта на релационните изчисления да намеря някакъв нов тип връзка, която би позволила това.
Също така за такива връзки (m2m) имате два избора, или да създадете комбиниран ключ в таблицата на линкера, така че комбинацията от полета да стане уникален запис (ако се интересувате от db оптимизация, това е по-бавният избор, но заема по-малко място). Алтернативно създавате трето поле с автоматично генерирана колона за идентификатор и го правите първичен ключ (за оптимизация на db това е по-бързият избор, но заема повече място).
В примера ви конкретно по-горе...
Това би било много към много връзка с таблицата с телефонни номера като таблица за свързване между компании и потребители. Както беше обяснено, за да сте сигурни, че никой телефонен номер не се повтаря, просто го задавате като първичен ключ или използвате друг първичен ключ и задавате полето за телефонен номер на уникален.
За този вид въпроси наистина зависи от това как ги формулирате. Какво ви кара да се обърквате относно това и как да преодолеете това объркване, за да видите решението, е просто. Преформулирайте проблема, както следва. Започнете, като попитате дали е едно към едно, ако отговорът е не, продължете напред. Следващият въпрос е един към много, ако отговорът е не продължете напред. Единствената останала опция е много към много. Бъдете внимателни, уверете се, че сте обмислили внимателно първите 2 въпроса, преди да продължите. Много неопитни хора в базата данни често усложняват въпроси, като дефинират едно към много, както много към много. Още веднъж, най-популярният тип връзка е едно към много (бих казал 90%), като много към много и едно към едно разделят останалите 10% съответно 7/3. Но тези цифри са само моя лична гледна точка, така че не ги цитирайте като стандартна статистика за индустрията. Целта ми е да се уверя, че определено не е едно към много, преди да избера много към много. Струва си допълнителните усилия.
Така че сега, за да намерите таблицата за свързване между двете, решете кои две са вашите основни таблици и какви полета трябва да бъдат споделени между тях. В този случай и фирмените, и потребителските маси трябва да споделят телефона. Следователно трябва да направите нова телефонна таблица като свързващ елемент.
Предупредителната аларма за неразбиране трябва да се покаже веднага щом решите, че никой от 3-те не работи за вас. Това трябва да е достатъчно, за да ви каже, че просто не формулирате правилно въпроса за връзката. С течение на времето ще се усъвършенствате в това, но това е основно умение и наистина трябва да бъде овладяно възможно най-скоро за вашата собствена здравина.
Разбира се, можете също да отидете до обектно-ориентирана база данни, която ще позволи редица други връзки, наречени "йерархични" връзки. Това е чудесно, ако и вие мислите да станете програмист. Но не бих препоръчал това, тъй като ще ви заболи главата, когато започнете да намирате начини да комбинирате различните видове взаимоотношения. Особено като се има предвид, че няма голяма нужда, тъй като почти всички бази данни в света се състоят само от тези 3 типа връзки, освен ако не са нещо супер дупер специално.
Надявам се това да е разумен отговор. Благодаря, че отделихте време да го прочетете.
