Antipatroon?
In het algemeen is de tweede tabel anti-patroon in de context van databaseontwerp. En, meer nog, het heeft een specifieke naam:Entity-Attribute-Value (EV). Er zijn enkele gevallen waarin het gebruik van dit ontwerp gerechtvaardigd is, maar dat zijn zeldzame gevallen - en zelfs daar kan het worden vermeden.
Waarom EAV slecht is
Ondersteuning voor gegevensintegriteit
Ondanks het feit dat een dergelijke structuur meer "flexibel" of "geavanceerder" lijkt te zijn, heeft dit ontwerp een zwak punt.
- Onmogelijk om verplichte kenmerken te maken . U kunt een kenmerk niet verplicht maken, aangezien het kenmerk nu als een rij wordt opgeslagen - en het enige teken dat dat kenmerk niet is ingesteld - is dat de bijbehorende rij afwezig is in de tabel. SQL staat je niet toe om zo'n beperking native te bouwen - dus je zult dat in de applicatie moeten controleren - en, ja, vraag je tabel elke keer op
- Vermenging van gegevenstypen . U kunt geen standaard SQL-gegevenstypen gebruiken. Omdat uw waardekolom een "supertype" moet zijn voor alle opgeslagen waarden erin. Dat betekent - u zult in het algemeen alle gegevens moeten opslaan als onbewerkte tekenreeksen . Dan zul je zien hoe pijnlijk het is om met datums te werken zoals met strings, elke keer gegevenstypes te casten, de gegevensintegriteit te controleren, enz.
- Onmogelijk om referentiële integriteit af te dwingen . In een normale situatie kunt u een externe sleutel gebruiken om uw waarden te beperken tot de waarden die zijn gedefinieerd in de bovenliggende tabel. Maar niet in dit geval - dat komt omdat referentiële integriteit wordt toegepast op elke rij in de tabel, maar niet voor rijwaarden. Dus - u verliest dit voordeel - en het is een van de fundamentele in relatie tot DB
- Onmogelijk om attribuutnamen in te stellen . Dat betekent dat u de attribuutnaam op DB-niveau niet goed kunt beperken. U schrijft bijvoorbeeld
"customer_name"als attribuutnaam in eerste geval - en een andere ontwikkelaar zal dat vergeten en"name_of_customer"gebruiken . En... het is oke, DB zal dat doorgeven en je zult eindigen met uren besteed aan het debuggen van deze zaak.
Rijreconstructie
Bovendien zal rijreconstructie in het algemeen verschrikkelijk zijn. Als je bijvoorbeeld 5 attributen hebt - dat zijn 5 self-table JOIN -s. Jammer voor zo'n eenvoudig - op het eerste gezicht - geval. Dus ik wil me niet eens voorstellen hoe je 20 attributen kunt behouden.
Kan het worden gerechtvaardigd?
Mijn punt is - nee. In RDBMS zal er altijd een manier zijn om dit te vermijden. Het is verschrikkelijk. En als EAV bedoeld is om te worden gebruikt, is de beste keuze misschien niet-relationeel databases.