enkele vaste tabel met meerdere kolommen versus flexibele abstracte tabellen

Bepaalde problemen moeten voordat worden opgehelderd en opgelost we kunnen een redelijke discussie aangaan.

Vereiste resolutie

Labels
In een beroep dat precisie vereist, is het belangrijk dat we nauwkeurige labels gebruiken om verwarring te voorkomen en zodat we kunnen communiceren zonder omslachtige beschrijvingen en kwalificaties te gebruiken.

Wat je hebt gepost als FixedTables, is Niet-genormaliseerd . Eerlijk genoeg, het kan een poging zijn tot de derde normale vorm, maar in feite is het een plat bestand, niet-genormaliseerd (niet "gedenormaliseerd). Wat u hebt gepost als abstracte tabellen is, om precies te zijn, Entity-Attribute-Value , wat bijna, maar niet helemaal, de zesde normaalvorm is, en daarom meer genormaliseerd is dan 3NF. Ervan uitgaande dat het correct wordt gedaan, natuurlijk.

Het niet-genormaliseerde platte bestand is niet "gedenormaliseerd". Het zit boordevol duplicatie (er is niets gedaan om herhalende groepen en dubbele kolommen te verwijderen of afhankelijkheden op te lossen) en nulls, het is in veel opzichten een prestatie-zwijn en voorkomt gelijktijdigheid.

Om te worden gedenormaliseerd, moet het eerst worden genormaliseerd, en dan de normalisatie een beetje teruggetrokken om een goede reden. Omdat het in de eerste plaats niet genormaliseerd is, kan het niet worden gedenormaliseerd. Het is gewoon niet-genormaliseerd.

Er kan niet worden gezegd dat het gedenormaliseerd is "voor prestaties", omdat het een prestatievarken is, het is de antithese van prestaties. Nou, ze hebben een rechtvaardiging nodig voor het gebrek aan geformaliseerd ontwerp], en "voor prestaties" is het. Zelfs de kleinste formele controle bracht de verkeerde voorstelling van zaken aan het licht (maar heel weinig mensen kunnen het geven, dus het blijft verborgen, totdat ze een buitenstaander krijgen om, je raadt het al, het enorme prestatieprobleem aan te pakken).

Genormaliseerde structuren presteren veel beter dan niet-genormaliseerde structuren. Meer genormaliseerde structuren (EAV/6NF) presteren beter dan minder genormaliseerde structuren (3NF/5NF).

Ik ben het eens met de strekking van OMG Ponies, maar niet met hun labels en definities

in plaats van te zeggen 'niet "denormaliseren" tenzij het moet' , ik zeg, 'Normaliseer trouw, punt uit' en 'als er een prestatieprobleem is, heb je niet correct genormaliseerd' .

Wikipedia
De vermeldingen voor Normale vormen en Normalisatie bieden definities die onjuist zijn; ze verwarren de normale vormen; ze ontbreken met betrekking tot het proces van normalisatie; en ze geven evenveel gewicht aan absurde of twijfelachtige NF's die lang geleden zijn ontkracht. Het resultaat is dat Wikipedia iets toevoegt aan een toch al verward en zelden begrepen onderwerp. Verspil dus geen tijd.

Maar om vooruitgang te boeken, zonder dat die verwijzing een belemmering vormt, wil ik dit zeggen.

De definitie van 3NF is stabiel en is niet veranderd.

Er is veel verwarring over de NF's tussen 3NF en 5NF. De waarheid is dat dit een gebied is dat de afgelopen 15 jaar vooruitgang heeft geboekt; en veel organisaties, zowel academici als verkopers met hun producten met beperkingen, sprongen over om een nieuw "normaal formulier" te creëren om hun aanbod te valideren. Allemaal in dienst van commerciële belangen en academisch ondeugdelijk. 3NF in zijn oorspronkelijke, ongemanipuleerde staat bedoeld en gegarandeerd bepaalde attributen.

De totale som is, 5NF is vandaag, wat 3NF 15 jaar geleden bedoeld was, en je kunt de commerciële scherts en de twaalf of zo "speciale" (commerciële en pseudo-academische) NF's ertussen overslaan, sommige waarvan zijn geïdentificeerd in Wikipedia, en zelfs dat in verwarrende bewoordingen.

Vijfde normaalvorm
Aangezien u de EAV in uw post hebt kunnen begrijpen en implementeren, zult u geen probleem hebben om het volgende te begrijpen. Natuurlijk is een echt relationeel model een vereiste, sterke sleutels, enz. Vijfde normaalvorm is, aangezien we de vierde overslaan:

Derde normaalvorm

wat in eenvoudige, definitieve bewoordingen is dat elke niet-sleutelkolom in elke tabel een 1::1-relatie heeft met de primaire sleutel van de tabel,

en geen andere niet-sleutelkolommen

Geen gegevensduplicatie (het resultaat, als normalisatie ijverig wordt gevorderd; niet bereikt door intelligentie of ervaring alleen, of door ernaar toe te werken als een doel zonder het formele proces)

geen update-afwijkingen (wanneer u ergens een kolom bijwerkt, hoeft u dezelfde kolom niet ergens anders bij te werken; de kolom bestaat op één en slechts één plaats).

Als je het bovenstaande begrijpt, kunnen 4NF, BCNF en alle dwaze "NF's" worden afgewezen, ze zijn vereist voor fysieke archiefsystemen, zoals gepromoot door academici, die nogal vreemd zijn aan het relationele model (Codd).
li>

Zesde normaalvorm

Het doel is het elimineren van ontbrekende gegevens (attribuutkolommen), ook bekend als eliminatie van nulls

Dit is de enige echte oplossing voor het Null-probleem (ook wel Handling Missing Values genoemd), en het resultaat is een database zonder Nulls. (Het kan bij 5NF met standaarden en Null-substituten, maar dat is niet optimaal.) Hoe je de ontbrekende waarden interpreteert en weergeeft, is een ander verhaal.

Technisch gezien is het geen echte normaalvorm, omdat het geen 5NF als voorwaarde heeft, maar het heeft een waarde

EAV versus zesde normaalvorm
Alle databases die ik heb geschreven, behalve één, zijn pure 5NF. Ik heb met een aantal EAV-databases gewerkt (beheerd, opgeknapt, verbeterd) en ik heb veel echte 6NF-databases geïmplementeerd. EAV is een losse implementatie van 6NF, vaak gedaan door mensen die geen goed begrip hebben van normalisatie en de NF's, maar die de waarde kunnen inzien van en de flexibiliteit van EAV nodig hebben. Jij bent een perfect voorbeeld.

Het verschil is dit:omdat het los is en omdat implementeerders geen referentie (6NF) hebben om trouw aan te zijn, implementeren ze alleen wat ze nodig hebben en schrijven ze het allemaal in code; dat wordt uiteindelijk een inconsistent model.

Terwijl een pure 6NF-implementatie wel een puur academisch referentiepunt heeft, en dus meestal strakker en consistenter is. Meestal wordt dit weergegeven in twee zichtbare elementen:

6NF heeft een catalogus om metadata te bevatten, en alles is gedefinieerd in metadata, niet in code. EAV heeft er geen, alles is in code (uitvoerders houden de objecten en attributen bij). Het is duidelijk dat een catalogus het toevoegen van kolommen en navigatie vergemakkelijkt en het maken van hulpprogramma's mogelijk maakt.

6NF biedt, indien begrepen, de echte oplossing voor het nulprobleem. EAV-implementers, omdat ze de 6NF-context niet hebben, verwerken ontbrekende gegevens in code, inconsistent of erger, laten nulls in de database toe. 6NF-implementers staan Nulls niet toe en gaan consequent en elegant om met ontbrekende gegevens, zonder codeconstructies (voor Null-verwerking; u moet natuurlijk nog steeds coderen voor ontbrekende gegevens).

bijv. Voor 6NF-databases met een catalogus heb ik een set proc's die de SQL [re]genereren die nodig is om alle SELECT's uit te voeren, en ik bied weergaven in 5NF voor alle gebruikers, zodat ze de onderliggende 6NF-structuur niet hoeven te kennen of te begrijpen . Ze worden uit de catalogus verdreven. Zo zijn wijzigingen eenvoudig en geautomatiseerd. EAV-types doen dat handmatig, vanwege het ontbreken van de catalogus.

Discussie

Nu kunnen we de discussie starten.

"Natuurlijk kan het abstracter zijn als de waarden vooraf zijn gedefinieerd (Voorbeeld:specialiteiten kunnen hun eigen lijst hebben)"

Zeker. Maar word niet te "abstract". Zorg voor consistentie en implementeer dergelijke lijsten op dezelfde EAV (of 6NF) manier als andere lijsten.

"Als ik de abstracte benadering hanteer, kan het heel flexibel zijn, maar query's zullen complexer zijn met veel joins. Maar ik weet niet of dit de prestaties beïnvloedt bij het uitvoeren van deze 'meer complexe' query's."

Joins zijn voetgangers in relationele databases. Het probleem is niet de database, het probleem is dat SQL omslachtig is bij het verwerken van joins, met name samengestelde sleutels.

EAV- en 6NF-databases hebben meer Joins, die net als voetgangers niet meer en niet minder zijn. Als je elke SELECT handmatig moet coderen, wordt het omslachtige echt omslachtig.

Het hele probleem kan worden geëlimineerd door (a) 6NF over EAV te gebruiken en (b) een catalogus te implementeren, waaruit u (c) alle basis-SQL kunt genereren. Elimineert ook een hele reeks fouten.

Het is een veel voorkomende mythe dat Joins op de een of andere manier kosten met zich meebrengen. Helemaal niet waar.

De join wordt tijdens het compileren geïmplementeerd, er is niets substantieels aan het 'kosten' van CPU-cycli.

Het probleem is de grootte van tabellen worden samengevoegd, niet de kosten van de Join tussen diezelfde tafels.

Het samenvoegen van twee tabellen met elk miljoenen rijen, op een correcte PK⇢FK-relatie, die elk de juiste indices hebben
(Uniek aan de bovenliggende [PK]-zijde; Uniek aan de onderliggende zijde [PK=ouder] FK + iets]
is onmiddellijk

Waar de onderliggende index niet uniek is, maar in ieder geval de leidende kolommen geldig zijn, is deze langzamer; waar er geen bruikbare index is, is het natuurlijk erg traag.

Dit heeft niets te maken met deelnamekosten.

Waar veel rijen worden geretourneerd, is de bottleneck het netwerk en de schijflay-out; niet de join-verwerking.

Daarom kunt u het zo "complex" krijgen als u wilt, er zijn geen kosten aan verbonden, SQL kan het aan.

Ik zou graag willen weten wat de voor- en nadelen van beide methoden zijn. Ik kan het me alleen maar voorstellen, maar ik heb niet de ervaring om dit te bevestigen.

5NF (of 3NF voor degenen die de progressie niet hebben gemaakt) is de gemakkelijkste en beste, in termen van implementatie; gebruiksgemak (zowel ontwikkelaars als gebruikers); en onderhoud.

Het nadeel is dat elke keer dat u een kolom toevoegt, u de databasestructuur (tabel DDL) moet wijzigen. Dat is in sommige gevallen prima, maar in de meeste gevallen niet, vanwege de aanwezige wijzigingsbeheer, behoorlijk belastend.

Ten tweede moet je bestaande code wijzigen (code die de nieuwe kolom afhandelt telt niet, want dat is een vereiste):waar goede standaarden worden geïmplementeerd, wordt dat geminimaliseerd; waar ze afwezig zijn, is de reikwijdte onvoorspelbaar.

Met EAV (dat is wat je hebt gepost), kunnen kolommen worden toegevoegd zonder DDL-wijzigingen. Dat is de enige reden waarom mensen ervoor kiezen. (code die de nieuwe kolom afhandelt telt niet, want dat is een vereiste). Als het goed wordt geïmplementeerd, heeft het geen invloed op bestaande code; zo niet, dan wel.

Maar je hebt EAV-compatibele ontwikkelaars nodig.

Als EAV slecht is geïmplementeerd, is het afschuwelijk, een ergere puinhoop dan 5NF dat slecht is gedaan, maar niet erger dan Unnormalised, wat de meeste databases zijn (ten onrechte voorgesteld als "gedenormaliseerd voor prestaties").

Natuurlijk is het nog belangrijker (dan in 5NF/3NF) om een sterke transactiecontext te hebben, omdat de kolommen veel meer verspreid zijn.

Evenzo is het essentieel om declaratieve referentiële integriteit te behouden:de rotzooi die ik heb gezien, was grotendeels te wijten aan het feit dat de ontwikkelaars DRI verwijderden omdat het "te moeilijk te onderhouden" werd. Het resultaat was, zoals je je kunt voorstellen, één moeder van een dataheap met overal dubbele 3NF/5NF-rijen en -kolommen. En inconsistente Null-afhandeling.

Er is geen verschil in prestatie, ervan uitgaande dat de server redelijkerwijs is geconfigureerd voor het beoogde doel. (Ok, er zijn specifieke optimalisaties die alleen mogelijk zijn in 6NF, die niet mogelijk zijn in andere NF's, maar ik denk dat dat buiten het bestek van deze thread valt.) En nogmaals, slecht uitgevoerde EAV kan onnodige knelpunten veroorzaken, niet meer dan Niet genormaliseerd.

Natuurlijk, als je met EAV gaat, raad ik meer formaliteit aan; koop de volledige pond; ga met 6NF; een catalogus implementeren; hulpprogramma's om SQL te produceren; Keer bekeken; consequent omgaan met ontbrekende gegevens; elimineren Nulls helemaal. Dit vermindert uw kwetsbaarheid voor de kwaliteit van uw ontwikkelaars; ze kunnen de esoterische problemen van EAV/6NF vergeten, Views gebruiken en zich concentreren op de app-logica.