MySQL backref - Page 1

Est-ce qu'un système de liens "backref" existe sous mysql ? Si oui, la performance en vaut elle la peine ?

---

explicatoin de ce que j'entends par backref :

On a une base de données "bibliothèque"

Une table contient les sujets, une table contient les livres. Un livre a un champ "sujet principal" qui est un lien vers la table sujet.

Le lien backref permet d'obtenir la liste des livres sur un sujet sans faire de select sur la table livre.

Le lien de type "setof" que représente "sujet principal" a un fonctionnement de retour qui permet de le prendre par l'autre bout

Ca gonfle souvent les quantités de données mais ça a l'énorme avantage d'augmenter les performances et de réduire le nombre de requètes.

---

Si je demande ça c'est parce que je voudrais être sur que ça existe de manière automatisée, c'est à dire que une fois le lien backref déclaré, un insert dans la table livre vienne peupler le backref sans que je soit obligé de le faire moimême ou par le biais d'un trigger bdd...

vince (./1) :
Ca gonfle souvent les quantités de données mais ça a l'énorme avantage d'augmenter les performances et de réduire le nombre de requètes.

mouaif, c'est bien quand on veut bourriner ton truc, mais si tu veux paginer par exemple, une requête avec bornes risque d'être plus performante non ? Même si le backref est en builtin...

(il me semble qu'il sait pas faire ça de manière automatisée, tu vas devoir te farcir des triggers...)

en fait j'ai un cas où on peut considérer que ça va être indispensable...

mais bon, tu as l'air de confirmer ce que je pensait : pas de backref en builtin...

et sinon, tu lui connais un équivalent (en nom) ? un synonyme...

tu peux tenter de passer par une procédure stockée, ça ferait déjà ça de gagné... mais ça reste pas du builtin.

Pour un nom ou synonyme... Je vois pas, mais ce que tu cherches, je pense qu'on peut dire que c'est une BDD objet de type celle de Zope

mouais mais je peux pas changer, mysql et rien d'autre.

(pour reprendre la comparaison, j'ai plus de 50 000 sujets et le nombre de livre ira croissant... et il n'y a pas de possibilité de "pagination puisque les requêtes sur les sujets peuvent se faire par lots de 1000. or pour chaque ligne du lot, il faut que sache au moins le nombre de livres sur le sujet et je me vois mal, pour une requête de lot qui est déjà conséquente, faire 1000 requêtes sur la base des livres... même avec les index ça reste lourd...)

stocker le nombre à chaque insertion dans la table sujet ? C'est bourrin, mais on peut considérer que tu vas moins insérer que consulter, donc tu vas perdre un pouieme à l'insertion et un peu en espace, et gagner x pouièmes à la consultation...

Tes contraintes sont plutôt où ? hard limité ? quelle partie doit être la plus optimisée (a priori celle la plus réalisée et celle considérée comme la plus banale par l'utilisateur, m'enfin ça dépend de l'utilisation finale & contraintes)

kim (./2) :
triggers...)

Euuuh mySQL 5 implémente vraiment les triggers ? Je pensais que c'était en allégé et qu'il fallait attendre la version 6 (à moins que vince soit déjà en 6 - ou encore que je me trompe )

Voir là et là
A priori ça devrait fonctionner au moins dans le cas de vince, mais c'est vrai que ça n'a pas l'air complètement finalisé encore (ce qui n'est pas étonnant vu que c'est encore relativement récent )

Ok, merci

les triggers sont largement expérimentaux sous mysql5, c'est une des raisons qui fait que j'aimerais m'en passer

vince (./5) :
pour une requête de lot qui est déjà conséquente, faire 1000 requêtes sur la base des livres

Ça ressemble au syndrome "n+1" où tu fais une requête qui te renvoie n éléments puis n requêtes pour avoir des détails sur chacun de ces éléments. Tu peux faire une jointure dans la première requête, sinon tu peux faire une deuxième requête avec un IN (voire plusieurs si les 1 000 clés font que la requête est un peu trop grande ).
Enfin ma réponse est carrément basique et montre mon ignorance des questions de performance, mais en tout cas je souhaitais répondre sur le fait de faire n+1 requêtes c'est pas normal.

Sinon je comprends pas très bien l'impossibilité de faire un SELECT sur les livres, si tu veux des livres ça va être dur, non ?
Et au final le backref, c'est quoi? Par "set of", tu veux dire que les données sont entièrement dupliquées, ou bien qu'il garde un set de clés primaires (ce qui ferait de la redondance aussi mais quand même à une autre échelle).

Et pour le nombre de livres, comme la dit kim, un compteur ça fait très bien l'affaire tant que tu peux t'assurer de sa mise à jour lors des insertions.

un lien setof c'est ce qu'on a dans la table livre pour pointer sur le sujet

BiHi (./11) :
Tu peux faire une jointure dans la première requête

C'est la fausse bonne idée : en faisant une jointure, tu récupères deux tables, c'est une cata en termes de performances