Først , nogle gange gør denne model det meget nemmere at forespørge data. Jeg stillede et spørgsmål for et par dage siden her og nogle brugere foreslog, hvorfor jeg ikke ændrede min model til en 1NF-formular for at gøre det lettere at forespørge data. Først da de indså, at jeg sad fast med dette design, gav de nogle svar på spørgsmålet. Pointen er, at jeg var så heldig at have kun 12 kolonner, der skulle opsummeres; Ellers, hvis min tabel indeholdt 300 kolonner, var der måske ingen brugere, der gad at skrive en forespørgsel til det problem. :-)
Anden , nogle gange er implementeringen af dette design lettere på grund af nogle begrænsninger, der naturligt pålægges af databaser. Hvis din meta_key værdier indeholder nogle lange værdier, der er større end 30 tegn, enten skal du forkorte værdierne og foretage kortlægningen et sted, ellers ville dette muligvis være den eneste mulighed, du kunne have.
Endelig , ydeevne er meget vigtig; det er rigtigt. Men på den anden side er der visse teknikker, du kan anvende for at forbedre ydeevnen; ved at oprette korrekte indekser, partitioneringstabeller og så videre.
I dette tilfælde er bordstørrelserne meget små. Så medmindre dine forespørgsler er meget komplicerede, såsom at have tunge beregninger og komplicerede sammenføjninger og aggregeringer, og hvis applikationen ikke er følsom over for små tidsbrøker, gætter jeg på, at du ikke ville lide under ydeevnen, hvis du brugte denne model.
I slutningen , hvis du stadig er for meget bekymret over ydeevnen, vil jeg foreslå at oprette begge modeller, udfylde dem med nogle tilfældige eller rigtige data og analysere planomkostningerne for at se, hvilken model der passer bedst til dine behov.