Antimønster?
I almindelige tilfælde er den anden tabel anti-mønster i forbindelse med databasedesign. Og endnu mere har den et specifikt navn:Entity-Attribute-Value (EAV). Der er nogle tilfælde, hvor brugen af dette design er berettiget, men det er sjældne tilfælde - og selv der kan det undgås.
Hvorfor EAV er dårligt
Understøttelse af dataintegritet
På trods af det faktum, at en sådan struktur synes at være mere "fleksibel" eller "avanceret", har dette design svagheder.
- Umulligt at lave obligatoriske attributter . Du kan ikke gøre nogle attribut obligatoriske, da attribut nu er gemt som en række - og det eneste tegn på, at attribut ikke er sat - er, at den tilsvarende række mangler i tabellen. SQL vil ikke tillade dig at bygge en sådan begrænsning indbygget - så du bliver nødt til at kontrollere det i applikationen - og ja, forespørge din tabel hver gang
- Blanding af datatyper . Du vil ikke være i stand til at bruge SQL standard datatyper. Fordi din værdikolonne skal være en "supertype" for alle gemte værdier i den. Det betyder - du skal generelt gemme alle data som rå strenge . Så vil du se, hvor smertefuldt det er at arbejde med datoer som med strenge, caste datatyper hver gang, tjekke dataintegritet osv.
- Umulligt at håndhæve referentiel integritet . I en normal situation kan du bruge fremmednøgle til at begrænse dine værdier med dem, som er defineret i den overordnede tabel. Men ikke i dette tilfælde - det er fordi referentiel integritet anvendes på hver række i tabellen, men ikke for rækkeværdier. Så - du mister denne fordel - og det er en af grundlæggende i forhold DB
- Umulligt at angive attributnavne . Det betyder - du kan ikke begrænse attributnavnet på DB-niveau korrekt. For eksempel skal du skrive
"customer_name"som attributnavn i første tilfælde - og en anden udvikler vil glemme det og bruge"name_of_customer". Og... det er ok, DB vil bestå det, og du vil ende med timer brugt på at fejlfinde denne sag.
Rekonstruktion af række
Derudover vil rækkegenopbygning være forfærdelig i almindelige tilfælde. Hvis du f.eks. har 5 attributter - det vil være 5 self-table JOIN -s. Ærgerligt for sådan en simpel - ved første øjekast - sag. Så jeg vil ikke engang forestille mig, hvordan du vil bevare 20 attributter.
Kan det retfærdiggøres?
Min pointe er - nej. I RDBMS vil der altid være en måde at undgå dette på. Det er forfærdeligt. Og hvis EAV er beregnet til at blive brugt, så kan det bedste valg være ikke-relationel databaser.