Antimönster?
I vanliga fall är den andra tabellen antimönster i samband med databasdesign. Och ännu mer, den har ett specifikt namn:Entity-Attribute-Value (EAV). Det finns vissa fall när det är motiverat att använda denna design, men det är sällsynta fall - och även där kan det undvikas.
Varför EAV är dåligt
Stöd för dataintegritet
Trots det faktum att en sådan struktur verkar vara mer "flexibel" eller "avancerad", har denna design svagheter.
- Omöjligt att göra obligatoriska attribut . Du kan inte göra något attribut obligatoriskt, eftersom attribut nu lagras som en rad - och det enda tecknet på att attributet inte är satt - är att motsvarande rad saknas i tabellen. SQL kommer inte att tillåta dig att bygga en sådan begränsning naturligt - därför måste du kontrollera det i applikationen - och, ja, fråga din tabell varje gång
- Blandning av datatyper . Du kommer inte att kunna använda SQL-standarddatatyper. Eftersom din värdekolumn måste vara en "supertyp" för alla lagrade värden i den. Det betyder att du i allmänhet måste lagra all data som råsträngar . Då kommer du att se hur smärtsamt det är att arbeta med datum som med strängar, casta datatyper varje gång, kontrollera dataintegritet, etc.
- Omöjligt att upprätthålla referensintegritet . I normala situationer kan du använda främmande nyckel för att begränsa dina värden med de som är definierade i den överordnade tabellen. Men inte i det här fallet - det beror på att referensintegritet tillämpas på varje rad i tabellen, men inte för radvärden. Så - du kommer att förlora denna fördel - och det är en av grundläggande i relation DB
- Omöjligt att ange attributnamn . Det betyder - du kan inte begränsa attributnamnet på DB-nivå ordentligt. Till exempel kommer du att skriva
"customer_name"som attributnamn i första fallet - och en annan utvecklare kommer att glömma det och använda"name_of_customer". Och... det är ok, DB kommer att klara det och du kommer att sluta med timmar som spenderas på att felsöka det här fallet.
Rekonstruktion av rad
Dessutom kommer radrekonstruktion att vara hemskt i vanliga fall. Om du till exempel har 5 attribut - det kommer att vara 5 självbord JOIN -s. Synd för ett så enkelt - vid första anblick - fall. Så jag vill inte ens föreställa mig hur du ska behålla 20 attribut.
Kan det motiveras?
Min poäng är - nej. I RDBMS kommer det alltid att finnas ett sätt att undvika detta. Det är hemskt. Och om EAV är tänkt att användas, kan bästa valet vara icke-relationellt databaser.