À l'heure actuelle, je prévois d'ajouter un système de filtrage à mon site.
Exemples: P>
table(ID, KEY, VALUE)
4 Réponses :
Ce que vous suggérez est connu sous le nom de structure de valeur d'attributs d'entité et est Au lieu de cela, je vous recommanderais de créer une table qui représente chaque type d'entité et que chaque table peut donc comporter des attributs (colonnes) spécifiques à ce type d'entité.
Pour convertir les données en colonnes dans une requête de résultat au fur et à mesure que vous recherchez, vous devrez créer ce qu'on appelle souvent une requête de crosstab. Il y a des moteurs de rapport qui le feront et vous pouvez le faire du code, mais la plupart des produits de base de données ne le feront pas de manière native (signification sans construire la chaîne SQL manuellement). La performance bien sûr ne sera pas bonne si vous avez beaucoup de données et que vous rencontrez des problèmes filtrant sur les données. Par exemple, supposons que certaines des valeurs soient censées être numériques. Étant donné que la valeur de la valeur de l'EAV est probablement une chaîne, vous devrez voter ces valeurs à un entier avant de pouvoir filtrer sur eux et suppose que les données seront convertibles en entiers.
Le Modèle d'attributs d'entité modèle que vous suggérez pourrait correspondre à Ce scénario.
En ce qui concerne la requête filtrante, vous devez comprendre qu'avec le modèle EAV, vous sacrifiez beaucoup de puissance de requête. Cela peut donc devenir assez délicat. Cependant, cela un moyen de s'attaquer à votre problème: P>
+-------+ | id | +-------+ | mango | +-------+ 1 row in set (0.00 sec)
Wow cela a l'air assez compliqué. Merci pour la solution. Il y a beaucoup de gens s'opposant à moi en utilisant cette conception, alors pour l'instant, je considère sérieusement si je devrais utiliser le modèle EVA
@sadvaw: L'opposition provient principalement du fait que lorsque vous utilisez le modèle EAV dans une base de données relationnelle, c'est comme utiliser une camionnette pour vous transporter autour de la ville: vous n'utilisez donc pas pour ce qu'il a été construit. Cependant, il peut encore être fait et la faisabilité de telle dépend souvent de la balance (combien vous le faites, ou quelle taille). Par conséquent, je dirais que si tout ce que vous faites dans la base de données est-ce, alors j'envisagerais en fait des alternatives à un SGBDM. Toutefois, si vous avez une base de données plus grande et que ce n'est qu'une petite partie, ces considérations pourraient être moins importantes.
Le prix que vous payez pour la conception de table simpliste à ce stade vous coûtera en termes de performances à long terme. En utilisant ORM afin de réduire le coût de modification de la base de données pour adapter les données dans une structure appropriée probablement être un bon investissement, même malgré le coût de performance d'ORM.
Sinon, vous pouvez rechercher un "orje inverse" qui mappe le code de votre base de données, qui bénéficie d'être moins coûteux et d'avoir une performance plus élevée. (Coût de départ légèrement plus élevé par rapport à l'orj, mais de meilleures performances et fiabilité à long terme.)
C'est un problème coûteux, quel que soit la façon dont vous le découpez. Voulez-vous payer maintenant avec le temps de développement ou payer plus tard lorsque vos réservoirs de performance? ("Payer plus tard" est la mauvaise réponse.)
Pouvez-vous recommander une conception de table qui correspond à votre réponse? Je ne comprends pas vraiment ce que vous parlez de.
Je suis tombé sur le nom de la théorie que je faisais allusion à: Anchor Modeling. La source est un peu académique: Syslab.dsv.su.se/profiles/blogs / Anchor-Modeling Pour que vous puissiez trouver cette explication un peu plus facile à digérer: Askmonty.org/ wiki / manuel: TABLE_ELIMINATION Le point de traduction de la base de données de procédure (liée ou séparée) (Techniques ORM ou ORM) est de réduire la quantité de code que vous devez écrire pour accéder à une structure de données spécialisée plus complexe et supérieure Performance, normalisation et caractéristiques relationnelles.
Les suivants ont fonctionné pour moi:
SELECT * FROM mytable t WHERE
t.key = "key" AND t.value = "value" OR
t.key = "key" AND t.value = "value" OR
....
t.key = "key" AND t.value = "value"
GROUP BY t.id having count(*)=3;
C'est à ma grande surprise que Reddit utilise de manière approfondie Eva. Carsonified.com/blog/dev/...