Je travaille sur une plateforme où les ID utilisateur uniques sont des ID d'identité d'un pool d'identités Amazon Cognito. Qui ressemblent à ceci : "us-east-1:128d0a74-c82f-4553-916d-90053e4a8b0f"
La plateforme dispose d'une base de données MySQL qui contient une table d'éléments que les utilisateurs peuvent consulter. J'ai besoin d'ajouter une table de favoris qui contient chaque élément favori de chaque utilisateur. Cette table pourrait potentiellement contenir des millions de lignes.
La structure de la table 'favoris' ressemblerait à ceci :
userID, itemID, dateAddedoù l'userID et l'itemID ensemble forment une clé primaire composite.
Je comprends que ce type d'userID (pratiquement un UUID étendu, qui doit être stocké en tant que char ou varchar) offre de mauvaises performances en termes d'indexation. Donc l'utiliser comme clé ou index pour des millions de lignes est déconseillé.
Ma question est : Ma compréhension est-elle correcte, et devrais-je m'inquiéter des performances à l'avenir en raison de cette clé ? Y a-t-il des mesures que je peux prendre pour réduire les risques de performance ?
Mes connaissances globales en base de données ne sont pas excellentes, donc si c'est un gros problème...Déplacer la liste de favoris vers une table NoSQL (où l'userID en tant que clé permettrait un temps d'accès constant), et récupérer un tableau d'ID d'éléments favoris, à utiliser dans une requête SELECT...WHERE IN, serait-il une alternative acceptable ?
Merci beaucoup !
