sql >> Database teknologi >  >> RDS >> Mysql

Databasedesign:EAV-muligheder?

Selvom det er minimalistisk som vist, introducerer attributtabellen i Model2 konceptet metadata ind i blandingen, med alt det gode der kommer af det. Der er andre fordele ved Model2, for eksempel præstationsgevinsten forbundet med mindre rækkestørrelse (af værditabellen), men jeg vil gerne fokusere på metadata-konceptet.

Selv som det er Model2's attributtabel udgør et lager af alle gyldige attributter (med model1 skulle man køre en slags samlet forespørgsel for at få sådan en liste). Også og som det er , er lageret tilstrækkeligt til at introducere fremmednøglebegrænsninger for at hjælpe med at opretholde datasættets integritet (med model 1 ville man have brug for eksterne former for validering af værdierne gemt i attributkolonnen.

Med et par enkle tilføjelser kan attributtabellen blive et alsidigt depot, som kan bruges til forskellige formål. Tabellen kan f.eks. indeholde nogle af følgende

  • oplysninger såsom det visningsvenlige navn på hver attribut
  • nogle flag, der angiver felttypen (numerisk vs. streng vs. dato osv.), til differentieret håndtering/behandling
  • den særlige værditabel, hvor den underliggende attribut er gemt (modellen viser kun én tabel, men optimering/skalering beder nogle gange om opdeling af tabellerne)
  • det faktum, at attributten kan gemmes som sin egen kolonne i "Værdi"-tabellen (igen en form for optimering, der i det væsentlige får det bedste fra begge verdener:fleksibiliteten af ​​skemaet for EAV-modellen, men ydeevnen af ​​traditionelle relationel model for de attributter, der er de mest brugte og/eller de mest almindelige for alle enheder.
  • evnen til at omdøbe attributter uden at forstyrre hovedtabellen. Ændringer kun på metadataniveau.
  • forskellige applikationsorienterede semantikker. For eksempel indikatorer på, at en bestemt egenskab skal tilbydes som et af de grundlæggende vs. avancerede søgefelter.

I en nøddeskal bliver attributtabellen en ressource, som gør det muligt for applikationen at være virkelig datadrevet (eller mere præcist, meta datadrevet). Faktisk kan du også lide en enhedstabel, dvs. en, hvor metadataene vedrørende de forskellige entitetstyper er indsamlet:hvilke er de forskellige enhedstyper, hvilke attributter er tilladt for hvilken enhedstype osv.

Nu... vær opmærksom på kommentaren fra zerkms , under selve spørgsmålet. På trods af alle dens fordele kommer EAV-modellen også med sin del af ulemper og udfordringer, som antydet kompleksiteten af ​​de forespørgsler, der kommer til at tænke på, og også præstationsproblemer. Disse bekymringer bør dog ikke diskvalificere, a priori, EAV:der er mange tilfælde, hvor EAV er en bedre tilgang.
Forudsat at EAV er valget, så Model2, eller endda noget lidt mere sofistikeret er definitivt bedre end model1.



  1. MySQL, fejl 126:Forkert nøglefil til tabel

  2. En måde at få et indekssøgning efter et førende %jokertegn

  3. Opretter du en brugerdefineret MySQL-funktion?

  4. Sådan får du sidste uges data i MySQL