jedna pevná tabulka s více sloupci vs flexibilní abstraktní tabulky

Některé problémy je třeba vyjasnit a vyřešit před můžeme vstoupit do rozumné diskuse.

Předběžné rozlišení

1. Štítky
   V profesi, která vyžaduje přesnost, je důležité, abychom používali přesné štítky, abychom se vyhnuli zmatkům a abychom mohli komunikovat, aniž bychom museli používat sáhodlouhé popisy a kvalifikátory.

   To, co jste zveřejnili jako FixedTables, je Nenormalizované . Je to docela slušné, může to být pokus o třetí normální formu, ale ve skutečnosti je to plochý soubor, nenormalizovaný (nikoli „denormalizovaný). To, co jste zveřejnili jako AbstractTables, je přesněji Entity-Attribute-Value , což je téměř, ale ne tak docela, šestá normální forma, a je proto více normalizovaná než 3NF. Samozřejmě za předpokladu, že je to provedeno správně.

   • Nenormalizovaný plochý soubor není "denormalizovaný". Je přeplněný duplicitou (nebylo uděláno nic pro odstranění opakujících se skupin a duplicitních sloupců nebo vyřešení závislostí) a nulových hodnot, je to v mnoha ohledech výkonnostní prase a zabraňuje souběžnosti.

   • Aby mohl být denormalizován, musí být nejprve normalizován a poté normalizace z nějakého dobrého důvodu trochu ustoupila. Vzhledem k tomu, že v první řadě není normalizován, nemůže být denormalizován. Je to prostě nenormalizované.

   • Nedá se říci, že by byl denormalizován „pro výkon“, protože jako výkonnostní prase je pravým opakem výkonu. Potřebují ospravedlnění pro nedostatek formalizovaného designu] a "pro výkon" to je. I sebemenší formální zkoumání odhalilo nepravdivé prohlášení (ale jen velmi málo lidí to může poskytnout, takže zůstává skryté, dokud nedostanou někoho zvenčí, aby se zabýval, uhodli jste, masivní problém s výkonem).

   • Normalizované struktury fungují mnohem lépe než nenormalizované struktury. Více normalizované struktury (EAV/6NF) fungují lépe než méně normalizované struktury (3NF/5NF).

   • Souhlasím s názorem OMG Ponies, ale ne s jejich popisky a definicemi

   • spíše než říkat 'nedenormalizujte, pokud nemusíte' , říkám:'Normalizujte věrně, tečka' a 'pokud se vyskytne problém s výkonem, neprovedli jste správnou normalizaci' .

2. Wikipedie
   Položky pro Normální formuláře a Normalizace nabízejí definice, které jsou nesprávné; matou Normální formy; v procesu normalizace chybí; a přikládají stejnou váhu absurdním nebo pochybným NF, které byly odhaleny již dávno. Výsledkem je, že Wikipedie přidává k již tak zmatenému a jen zřídka srozumitelnému tématu. Takže neztrácejte čas.

   Abychom však pokročili, aniž by tento odkaz představoval překážku, dovolte mi říci toto.

   • Definice 3NF je stabilní a nezměnila se.
   • Mezi 3NF a 5NF dochází k mnoha záměnám mezi NF. Pravdou je, že jde o oblast, která za posledních 15 let pokročila; a mnoho organizací, akademiků i prodejců se svými produkty s omezeními, skočilo do vytvoření nové „normální formy“, aby ověřili své nabídky. Všechny slouží komerčním zájmům a jsou akademicky nevhodné. 3NF ve svém původním nepoškozeném stavu zamýšlel a zaručoval určité atributy.
   • Součet je 5NF dnes, tím, čím měl být 3NF před 15 lety, a můžete přeskočit komerční žertování a přibližně dvanáct „speciálních“ (komerčních a pseudoakademických) NF mezi tím, z nichž jsou identifikovány ve Wikipedii, a to i v matoucích termínech.

3. Pátý normální formulář
   Protože jste byli schopni porozumět a implementovat EAV ve svém příspěvku, nebudete mít problém porozumět následujícímu. Předpokladem je samozřejmě skutečný relační model, silné klávesy atd. Pátá normální forma je, protože vynecháváme čtvrtou:

   • Třetí normální formulář
     • což jednoduše definitivně znamená, že každý neklíčový sloupec v každé tabulce má vztah 1::1 k primárnímu klíči tabulky,
     • a do žádných jiných neklíčových sloupců
   • Nulová duplicita dat (výsledek, pokud normalizace postupuje pilně; nedosáhne se pouze inteligencí nebo zkušenostmi, ani prací na dosažení cíle bez formálního procesu)
   • žádné anomálie aktualizace (když někde aktualizujete sloupec, nemusíte aktualizovat stejný sloupec umístěný někde jinde; sloupec existuje pouze na jednom místě).
   • Pokud rozumíte výše uvedenému, 4NF, BCNF a všechny hloupé „NF“ lze odmítnout, jsou vyžadovány pro fyzické systémy evidence záznamů, jak je propagují akademici, zcela cizí relačnímu modelu (Codd).
   li>

4. Šestý normální formulář

   • Účelem je eliminace chybějících dat (sloupce atributů), neboli eliminace null
   • Toto je jediné skutečné řešení problému Null (také nazývaného Handling Missing Values) a výsledkem je databáze bez hodnot Null. (Lze to udělat na 5NF se standardy a nullovými náhradami, ale to není optimální.) Jak interpretujete a zobrazujete chybějící hodnoty, je jiný příběh.
   • Technicky to není pravá normální forma, protože nemá 5NF jako nezbytnou podmínku, ale má hodnotu

5. EAV vs. šestá normální forma
   Všechny databáze, které jsem napsal, kromě jedné, jsou čistých 5NF. Pracoval jsem s (spravoval, opravoval, vylepšoval) několika databázemi EAV a implementoval jsem mnoho skutečných databází 6NF. EAV je volná implementace 6NF, kterou často provádějí lidé, kteří nemají dobrý přehled o normalizaci a NF, ale kteří vidí hodnotu v EAV a potřebují flexibilitu. Jste dokonalým příkladem.

   Rozdíl je tento:protože je to volné a protože implementátoři nemají referenci (6NF), které by mohli být věrní, implementují pouze to, co potřebují, a vše zapíší do kódu; což skončí jako nekonzistentní model.

   Zatímco čistá implementace 6NF má čistě akademický referenční bod, a proto je obvykle přísnější a konzistentní. Obvykle se to zobrazuje ve dvou viditelných prvcích:

   • 6NF má katalog obsahující metadata a vše je definováno v metadatech, nikoli v kódu. EAV žádný nemá, vše je v kódu (implementátoři sledují objekty a atributy). Katalog samozřejmě usnadňuje přidávání sloupců, navigaci a umožňuje vytváření utilit.
   • Po pochopení 6NF poskytuje skutečné řešení The Null Problem. Implementátoři EAV, protože chybí kontext 6NF, zacházejí s chybějícími daty v kódu, nekonzistentně nebo v horším případě umožňují v databázi hodnoty Null. Implementátoři 6NF nepovolují nulové hodnoty a zacházejí s chybějícími daty konzistentně a elegantně, aniž by vyžadovali konstrukty kódu (pro manipulaci s nulami; chybějící data samozřejmě stále musíte kódovat).

Např. Pro databáze 6NF s katalogem mám sadu procesů, které [znovu] vygenerují SQL potřebné k provedení všech SELECTů, a poskytuji pohledy v 5NF pro všechny uživatele, takže nepotřebují znát nebo rozumět základní struktuře 6NF. . Jsou vyřazeny z katalogu. Změny jsou tedy snadné a automatické. Typy EAV to dělají ručně, kvůli absenci katalogu.

Diskuse

Nyní můžeme zahájit diskusi.

"Samozřejmě to může být abstraktnější, pokud jsou hodnoty předdefinovány (Příklad:speciality mohou mít svůj vlastní seznam)"

Tak určitě. Nebuďte ale příliš „abstraktní“. Udržujte konzistenci a implementujte takové seznamy stejným způsobem EAV (nebo 6NF) jako ostatní seznamy.

"Pokud vezmu abstraktní přístup, může být velmi flexibilní, ale dotazy budou složitější se spoustou spojení. Nevím však, zda to ovlivní výkon provádění těchto "složitějších" dotazů."

1. Spojení jsou v relačních databázích pěší. Problémem není databáze, problém je v tom, že SQL je těžkopádné při manipulaci se spojeními, zejména složenými klíči.

2. Databáze EAV a 6NF mají více spojení, které jsou stejně pěší, nic víc, nic méně. Pokud musíte kódovat každý SELECT ručně, jistě, těžkopádný bude opravdu těžkopádný.

3. Celý problém lze odstranit (a) přechodem na 6NF přes EAV a (b) implementací katalogu, ze kterého (c) vygenerujete všechna základní SQL. Eliminuje také celou třídu chyb.

4. Je běžným mýtem, že spojení mají nějakou cenu. Naprosto nepravdivé.

   • Spojení je implementováno v době kompilace, není zde nic podstatného pro „cenu“ cyklů CPU.
   • Problémem je velikost tabulek spojení, nikoli náklady na spojení mezi stejnými stoly.
   • Spojení dvou tabulek s miliony řádků ve správném vztahu PK⇢FK, z nichž každá má příslušné indexy
     (Unikátní na nadřazené [PK] straně; Jedinečné na Podřízené straně [PK=rodič FK + něco]
     je okamžité
   • Tam, kde Child index není jedinečný, ale jsou platné alespoň úvodní sloupce, je pomalejší; tam, kde není užitečný index, je to samozřejmě velmi pomalé.
   • Nic z toho nemá co dělat s náklady na připojení.
   • Tam, kde je vráceno mnoho řádků, bude úzkým místem síť a rozložení disku; ne zpracování spojení.

5. Proto můžete být "komplexní", jak chcete, nic nestojí, SQL to zvládne.

Zajímalo by mě, jaké jsou výhody a nevýhody obou metod. Sám si to umím představit, ale nemám zkušenosti, abych to potvrdil.

1. 5NF (nebo 3NF pro ty, kteří neudělali pokrok) je nejjednodušší a nejlepší z hlediska implementace; snadnost použití (vývojáři i uživatelé); a údržbu.

   • Nevýhodou je, že pokaždé, když přidáte sloupec, musíte změnit strukturu databáze (tabulka DDL). To je v pořádku, v některých případech, ale ne ve většině případů, kvůli kontrole změny na místě, docela obtížné.
   • Zadruhé musíte změnit stávající kód (kód zpracovávající nový sloupec se nepočítá, protože to je nezbytně nutné):tam, kde jsou implementovány dobré standardy, je to minimalizováno; tam, kde chybí, je rozsah nepředvídatelný.

2. EAV (což je to, co jste zveřejnili), umožňuje přidání sloupců bez změn DDL. To je jediný důvod, proč si to lidé vybírají. (kód zpracovávající nový sloupec se nepočítá, protože je to nutné). Pokud je implementována dobře, neovlivní stávající kód; pokud ne, bude.

3. Ale potřebujete vývojáře schopné EAV.

   • Když je EAV implementováno špatně, je to ohavné, horší nepořádek než 5NF udělaný špatně, ale není o nic horší než Unnormalised, což je to, co existuje většina databází (chybně uváděné jako "denormalizované pro výkon").
   • Samozřejmě je ještě důležitější (než v 5NF/3NF) udržovat silný transakční kontext, protože sloupce jsou mnohem více distribuované.
   • Podobně je nezbytné zachovat deklarativní referenční integritu:nepořádky, které jsem viděl, byly z velké části způsobeny tím, že vývojáři odstranili DRI, protože se stalo „příliš těžké na údržbu“, výsledkem byla, jak si dokážete představit, jedna matka haldy dat s duplicitními řádky a sloupci 3NF/5NF po celém místě. A nekonzistentní zpracování Null.

4. Neexistuje žádný rozdíl ve výkonu, za předpokladu, že server byl přiměřeně nakonfigurován pro zamýšlený účel. (Dobře, existují specifické optimalizace, které jsou možné pouze v 6NF, které nejsou možné v jiných NF, ale myslím, že to je mimo rámec tohoto vlákna.) A opět, špatně provedená EAV může způsobit zbytečná úzká hrdla, ne více než Nenormalizované.

5. Samozřejmě, pokud půjdete s EAV, doporučuji více formálnosti; koupit celou korunu; jít s 6NF; implementovat katalog; nástroje pro vytváření SQL; Pohledy; důsledně zacházet s chybějícími daty; úplně odstranit nuly. To snižuje vaši zranitelnost vůči kvalitě vašich vývojářů; mohou zapomenout na esoterické problémy EAV/6NF, používat pohledy a soustředit se na logiku aplikace.