enkelt fast tabel med flere kolonner vs fleksible abstrakte tabeller

Visse problemer skal afklares og løses før vi kan indgå i en fornuftig diskussion.

Forudsat opløsning

1. Etiketter
   I et fag, der kræver præcision, er det vigtigt, at vi bruger præcise etiketter, for at undgå forvirring, og for at vi kan kommunikere uden at skulle bruge lange beskrivelser og kvalifikationer.

   Det, du har lagt op som faste tabeller, er Unormaliseret . Fair nok, det kan være et forsøg på tredje normal form, men i virkeligheden er det en flad fil, unormaliseret (ikke "denormaliseret). Det du har postet som AbstractTables er for at være præcis Entity-Attribute-Value , som er næsten, men ikke helt, sjette normalform, og er derfor mere normaliseret end 3NF. Forudsat at det er gjort korrekt, selvfølgelig.

   • Den unormaliserede flade fil er ikke "denormaliseret". Det er propfyldt med duplikering (der er ikke blevet gjort noget for at fjerne gentagne grupper og dublerede kolonner eller for at løse afhængigheder) og Nulls, det er en præstationssvin på mange måder og forhindrer samtidighed.

   • For at blive denormaliseret, skal den først normaliseres, og derefter trækkes normaliseringen lidt tilbage af en eller anden god grund. Da det ikke er normaliseret i første omgang, kan det ikke denormaliseres. Det er simpelthen unormaliseret.

   • Det kan ikke siges at være denormaliseret "for ydeevne", for at være et præstationssvin er det selve antitesen til præstation. Nå, de har brug for en begrundelse for manglen på formaliseret design], og "for ydeevne" er det. Selv den mindste formelle undersøgelse afslørede fejlrepræsentationen (men meget få mennesker kan give, så den forbliver skjult, indtil de får en udenforstående at tage fat på, du gættede rigtigt, det massive præstationsproblem).

   • Normaliserede strukturer fungerer langt bedre end unormaliserede strukturer. Mere normaliserede strukturer (EAV/6NF) klarer sig bedre end mindre normaliserede strukturer (3NF/5NF).

   • Jeg er enig i tanken om OMG Ponyer, men ikke deres etiketter og definitioner

   • i stedet for at sige 'må ikke "denormalisere", medmindre du er nødt til det' , jeg siger, 'Normaliser trofast, punktum' og 'hvis der er et ydeevneproblem, har du ikke normaliseret korrekt' .

2. Wikipedia
   Indtastningerne for Normal Forms og Normalization tilbyder definitioner, der er forkerte; de forveksler Normalformerne; de mangler med hensyn til normaliseringsprocessen; og de lægger lige vægt på absurde eller tvivlsomme NF'er, som er blevet afkræftet for længe siden. Resultatet er, at Wikipedia tilføjer et allerede forvirret og sjældent forstået emne. Så spild ikke din tid.

   Men for at komme videre, uden at denne henvisning udgør en hindring, så lad mig sige dette.

   • Definitionen af ​​3NF er stabil og er ikke ændret.
   • Der er meget forvirring af NF'erne mellem 3NF og 5NF. Sandheden er, at dette er et område, der har udviklet sig i løbet af de sidste 15 år; og mange organisationer, akademikere såvel som leverandører med deres produkter med begrænsninger, hoppede til at skabe en ny "normal formular" for at validere deres tilbud. Alle tjener kommercielle interesser og akademisk usunde. 3NF i sin oprindelige umanipulerede tilstand tilsigtet og garanteret visse attributter.
   • Summen er, at 5NF er i dag, hvad 3NF var beregnet til at være for 15 år siden, og du kan springe over de kommercielle drillerier og de omkring 12 "særlige" (kommercielle og pseudo-akademiske) NF'er derimellem, nogle hvoraf er identificeret i Wikipedia, og endda det i forvirrende vendinger.

3. Femte normalform
   Da du har været i stand til at forstå og implementere EAV i dit indlæg, vil du ikke have noget problem med at forstå følgende. Selvfølgelig er en ægte relationsmodel en forudsætning, stærke nøgler osv. Femte normalform er, da vi springer den fjerde over:

   • Tredje normalform
     • hvilket i enkle endegyldige termer er, at hver ikke-nøglekolonne i hver tabel har et 1::1 forhold til tabellens primære nøgle,
     • og ingen andre ikke-nøglekolonner
   • Nul dataduplikering (resultatet, hvis normaliseringen skrides flittigt frem, ikke opnået ved intelligens eller erfaring alene, eller ved at arbejde hen imod det som et mål uden den formelle proces)
   • ingen opdateringsanomalier (når du opdaterer en kolonne et sted, behøver du ikke at opdatere den samme kolonne, der er placeret et andet sted; kolonnen findes ét og kun ét sted).
   • Hvis du forstår ovenstående, kan 4NF, BCNF og alle de fjollede "NF'er" afvises, de er påkrævet for fysiske arkiveringssystemer, som fremmes af akademikere, som er ret fremmede for den relationelle model (Codd).

4. Sjette normalform

   • Formålet er eliminering af manglende data (attributkolonner), alias eliminering af Nulls
   • Dette er den eneste sande løsning på Null-problemet (også kaldet Håndtering af manglende værdier), og resultatet er en database uden Nulls. (Det kan gøres på 5NF med standarder og Null-erstatninger, men det er ikke optimalt.) Hvordan du fortolker og viser de manglende værdier er en anden historie.
   • Teknisk set er den ikke en ægte normalform, fordi den ikke har 5NF som en forudsætning, men den har en værdi

5. EAV vs. sjette normalform
   Alle de databaser, jeg har skrevet, undtagen én, er ren 5NF. Jeg har arbejdet med (administreret, rettet, forbedret) et par EAV-databaser, og jeg har implementeret mange ægte 6NF-databaser. EAV er en løs implementering af 6NF, ofte udført af folk, der ikke har et godt greb om Normalisering og NF'erne, men som kan se værdien i og har brug for fleksibiliteten i EAV. Du er et perfekt eksempel.

   Forskellen er denne:fordi det er løst, og fordi implementere ikke har en reference (6NF) at være tro mod, implementerer de kun det, de har brug for, og de skriver det hele i kode; det ender med at blive en inkonsekvent model.

   Hvorimod en ren 6NF-implementering har et rent akademisk referencepunkt, og derfor er den normalt strammere og konsekvent. Typisk vises dette i to synlige elementer:

   • 6NF har et katalog til at indeholde metadata, og alt er defineret i metadata, ikke kode. EAV har ikke en, alt er i kode (implementere holder styr på objekter og attributter). Et katalog letter naturligvis tilføjelsen af ​​kolonner, navigation og gør det muligt at danne hjælpeprogrammer.
   • 6NF, når det forstås, giver den sande løsning på Null-problemet. EAV-implementere, da de mangler 6NF-konteksten, håndterer manglende data i kode, inkonsekvent eller endnu værre, tillader Nulls i databasen. 6NF implementere forbyder Nulls og håndterer manglende data konsekvent og elegant uden at kræve kodekonstruktioner (til Null-håndtering; du skal selvfølgelig stadig kode for manglende data).

For eksempel. For 6NF-databaser med et katalog har jeg et sæt procs, der vil [gen]generere den SQL, der kræves for at udføre alle SELECT'er, og jeg leverer visninger i 5NF til alle brugere, så de ikke behøver at kende eller forstå den underliggende 6NF-struktur . De er drevet ud af kataloget. Derfor er ændringer lette og automatiserede. EAV-typer gør det manuelt på grund af fraværet af kataloget.

Diskussion

Nu kan vi starte diskussionen.