единична фиксирана таблица с множество колони срещу гъвкави абстрактни таблици

Някои проблеми трябва да бъдат изяснени и разрешени преди можем да влезем в разумна дискусия.

Предварително условие

1. Етикети
   В професия, която изисква прецизност, е важно да използваме точни етикети, за да избегнем объркване и за да можем да общуваме, без да се налага да използваме дълги описания и квалификатори.

   Това, което сте публикували като FixedTables, е Ненормализирано . Достатъчно справедливо, това може да е опит за трета нормална форма, но всъщност това е плосък файл, ненормализиран (не "денормализиран). Това, което сте публикували като AbstractTables, е, за да бъдем точни, Entity-Attribute-Value , което е почти, но не съвсем, шеста нормална форма и следователно е по-нормализирана от 3NF. Ако приемем, че е направено правилно, разбира се.

   • Ненормализираният плосък файл не е "денормализиран". Той е пълен с дублиране (нищо не е направено за премахване на повтарящи се групи и дублиращи се колони или за разрешаване на зависимости) и нулеви стойности, в много начини е висока производителност и предотвратява едновременността.

   • За да бъде денормализиран, първо трябва да бъде нормализиран и след това нормализирането да се оттегли малко по някаква добра причина. Тъй като не е нормализиран на първо място, не може да бъде денормализиран. Просто е ненормализиран.

   • Не може да се каже, че е денормализиран „за изпълнение“, тъй като бидейки свиня за изпълнение, той е самата антитеза на изпълнението. Е, те се нуждаят от обосновка за липсата на формализиран дизайн] и "за изпълнение" е това. Дори и най-малкият официален контрол разкри погрешното представяне (но много малко хора могат да го осигурят, така че то остава скрито, докато не получат външен човек, който да разгледа, както се досещате, огромния проблем с производителността).

   • Нормализираните структури се представят много по-добре от ненормализираните структури. По-нормализираните структури (EAV/6NF) се представят по-добре от по-малко нормализираните структури (3NF/5NF).

   • Съгласен съм с идеята на OMG Ponies, но не и с техните етикети и дефиниции

   • вместо да кажете „не „денормализирайте“, освен ако не трябва“ , казвам, „Нормализирайте вярно, точка“ и „ако има проблем с производителността, не сте нормализирали правилно“ .

2. Уикипедия
   Записите за нормални форми и нормализиране предлагат дефиниции, които са неправилни; те объркват нормалните форми; липсват по отношение на процеса на нормализиране; и те придават еднаква тежест на абсурдните или съмнителни НФ, които са били развенчани отдавна. Резултатът е, че Уикипедия добавя към вече объркана и рядко разбираема тема. Така че не си губете времето.

   Въпреки това, за да напреднете, без тази препратка да представлява пречка, позволете ми да кажа това.

   • Дефиницията на 3NF е стабилна и не се е променила.
   • Има много объркване на NF между 3NF и 5NF. Истината е, че това е област, която напредна през последните 15 години; и много организации, учени, както и доставчици с техните продукти с ограничения, скочиха да създадат нова "Нормална форма", за да валидират своите предложения. Всички обслужващи търговски интереси и академично нездравословни. 3NF в първоначалното си неподправено състояние, предназначени и гарантирани определени атрибути.
   • Общата сума е, 5NF е днес, това, което 3NF е било предназначено да бъде преди 15 години, и можете да пропуснете комерсиалните закачки и около дванадесетте „специални“ (търговски и псевдоакадемични) NF между тях, някои от които са идентифицирани в Уикипедия и дори това в объркващи термини.

3. Пета нормална форма
   Тъй като сте успели да разберете и приложите EAV в публикацията си, няма да имате проблем да разберете следното. Разбира се, истинският релационен модел е предпоставка, силни ключове и т.н. Петата нормална форма е, тъй като пропускаме четвъртата:

   • Трета нормална форма
     • което с прости и окончателни думи е, че всяка неключова колона във всяка таблица има връзка 1::1 с първичния ключ на таблицата,
     • и към никакви други неключови колони
   • Нулево дублиране на данни (резултатът, ако нормализирането се напредва усърдно; не се постига само с интелигентност или опит, или чрез работа за постигането им като цел без формален процес)
   • няма аномалии при актуализиране (когато актуализирате колона някъде, не е нужно да актуализирате същата колона, разположена някъде другаде; колоната съществува на едно и само едно място).
   • Ако разбирате горното, 4NF, BCNF и всички глупави „NFs“ могат да бъдат отхвърлени, те са необходими за физикализирани Системи за архивиране на записи, както се насърчава от академичните среди, доста чужди на Релационния модел (Codd).

4. Шеста нормална форма

   • Целта е елиминиране на липсващи данни (атрибутни колони), известен още като елиминиране на Nulls
   • Това е единственото истинско решение на нулевия проблем (наричан още обработка на липсващи стойности) и резултатът е база данни без нулеви стойности. (Може да се направи при 5NF със стандарти и нулеви заместители, но това не е оптимално.) Как интерпретирате и показвате липсващите стойности е друга история.
   • Технически не е истинска нормална форма, защото няма 5NF като предварително условие, но има стойност

5. EAV срещу шеста нормална форма
   Всички бази данни, които съм написал, с изключение на една, са чисти 5NF. Работил съм с (администрирани, коригирани, подобрени) няколко EAV бази данни и съм внедрил много истински 6NF бази данни. EAV е свободна реализация на 6NF, често се прави от хора, които не разбират добре нормализирането и NF, но които могат да видят стойността в EAV и се нуждаят от гъвкавостта на EAV. Вие сте идеален пример.

   Разликата е следната:тъй като е хлабав и тъй като имплементаторите нямат референция (6NF), на която да бъдат верни, те прилагат само това, от което се нуждаят, и пишат всичко това в код; това се оказва непоследователен модел.

   Като има предвид, че чистата 6NF реализация има чисто академична референтна точка и следователно обикновено е по-строга и последователна. Обикновено това се показва в два видими елемента:

   • 6NF има каталог, който съдържа метаданни и всичко е дефинирано в метаданни, а не в код. EAV няма такъв, всичко е в код (внедрителите следят обектите и атрибутите). Очевидно каталогът улеснява добавянето на колони, навигацията и позволява да се формират помощни програми.
   • 6NF, когато се разбере, предоставя истинското решение на нулевия проблем. EAV имплементаторите, тъй като отсъстват контекста 6NF, обработват липсващи данни в код, непоследователно или по-лошо, позволяват Nulls в базата данни. Имплементаторите на 6NF забраняват Nulls и обработват липсващите данни последователно и елегантно, без да изискват конструкции на код (за обработка на Null; все още трябва да кодирате за липсващи данни, разбира се).

напр. За 6NF бази данни с каталог имам набор от процеси, които ще [пре]генерират SQL, необходим за извършване на всички SELECTs, и предоставям изгледи в 5NF за всички потребители, така че те не трябва да знаят или разбират основната структура на 6NF . Те са изгонени от каталога. Така промените са лесни и автоматизирани. Типовете EAV правят това ръчно, поради липсата на каталог.

Дискусия

Сега можем да започнем дискусията.

„Разбира се, може да бъде по-абстрактно, ако стойностите са предварително определени (Пример:специалностите могат да имат свой собствен списък)“

Сигурен. Но не ставайте твърде "абстрактни". Поддържайте последователност и внедрявайте такива списъци по същия EAV (или 6NF) начин като другите списъци.

„Ако използвам абстрактния подход, той може да бъде много гъвкав, но заявките ще бъдат по-сложни с много присъединявания. Но не знам дали това се отразява на производителността, изпълнявайки тези „по-сложни“ заявки.“

1. Съединенията са пешеходни в релационни бази данни. Проблемът не е в базата данни, проблемът е, че SQL е тромав при обработката на обединения, особено на съставни ключове.

2. Базите данни EAV и 6NF имат повече Joins, които са също толкова пешеходни, нито повече, нито по-малко. Ако трябва да кодирате всеки SELECT ръчно, разбира се, тромавото става наистина тромаво.

3. Целият проблем може да бъде елиминиран чрез (а) преминаване с 6NF през EAV и (б) внедряване на каталог, от който можете (в) да генерирате целия основен SQL. Елиминира и цял клас грешки.

4. Често срещан мит е, че присъединяванията по някакъв начин имат цена. Напълно невярно.

   • Обединяването се изпълнява по време на компилиране, няма нищо съществено, което да „цени“ циклите на процесора.
   • Проблемът е в размера на таблиците се присъединява, а не цената на свързването между същите тези таблици.
   • Съединяване на две таблици с милиони редове всяка, на правилна PK⇢FK релация, всяка от които има съответните индекси
     (Уникален от страна на родител [PK]; Уникален от страна на дъщерите [PK=parent FK + нещо]
     е мигновено
   • Когато индексът Child не е уникален, но поне водещите колони са валидни, той е по-бавен; където няма полезен индекс, разбира се е много бавен.
   • Нищо от това не е свързано с цената на присъединяване.
   • Когато се връщат много редове, тесното място ще бъде мрежата и разположението на диска; не обработката на присъединяване.

5. Следователно можете да получите толкова "сложни", колкото искате, няма разходи, SQL може да се справи.

Бих искал да разбера какви са предимствата и недостатъците на двата метода. Мога да си представя сам, но нямам опит, за да потвърдя това.

1. 5NF (или 3NF за тези, които не са постигнали прогресия) е най-лесният и най-добрият по отношение на прилагането; лекота на използване (разработчици, както и потребители); и поддръжка.

   • Недостатъкът е, че всеки път, когато добавяте колона, трябва да променяте структурата на базата данни (таблица DDL). Това е добре в някои случаи, но не в повечето случаи, поради наличието на контрол върху промяната, доста обременително.
   • Второ, трябва да промените съществуващия код (обработването на кода с новата колона не се брои, защото това е наложително):когато се прилагат добри стандарти, това е сведено до минимум; където ги няма, обхватът е непредсказуем.

2. EAV (което сте публикували) позволява добавянето на колони без промени в DDL. Това е единствената причина хората да го избират. (обработването на кода с новата колона не се брои, защото това е наложително). Ако се приложи добре, това няма да повлияе на съществуващия код; ако не, ще стане.

3. Но имате нужда от разработчици, съвместими с EAV.

   • Когато EAV е внедрен зле, това е отвратително, по-лоша бъркотия от 5NF, направена лошо, но не по-лоша от Unnormalised, което е, което повечето бази данни съществуват (погрешно представени като „денормализирани за производителност“).
   • Разбира се, още по-важно е (отколкото в 5NF/3NF) да поддържате силен контекст на транзакциите, защото колоните са много по-разпределени.
   • По същия начин е от съществено значение да се запази целостта на декларативните препратки:бъркотията, която видях, се дължат до голяма степен на премахването на DRI от разработчиците, защото стана „твърде труден за поддръжка“, резултатът беше, както можете да си представите, една майка на купчина данни с дублиращи се 3NF/5NF редове и колони навсякъде. И непоследователна обработка на Null.

4. Няма разлика в производителността, ако приемем, че сървърът е разумно конфигуриран за предвидената цел. (Добре, има специфични оптимизации, които са възможни само в 6NF, които не са възможни в други NF, но мисля, че това е извън обхвата на тази тема.) И отново, EAV, направен лошо, може да причини ненужни затруднения, не повече от Ненормализиран.

5. Разбира се, ако използвате EAV, препоръчвам повече формалност; купете цялата лира; отидете с 6NF; внедряване на каталог; помощни програми за производство на SQL; Изгледи; да обработват липсващите данни последователно; елиминирайте напълно Nulls. Това намалява вашата уязвимост спрямо качеството на вашите разработчици; те могат да забравят за езотеричните проблеми на EAV/6NF, да използват Views и да се концентрират върху логиката на приложението.