Meilleure pratique pour le suivi hiérarchique des ressources MySQL

Question

Je suis en train d'écrire un tracker d'actifs de projets en ligne, mais je suis nouveau sur MySQL. Quel serait le meilleur moyen de suivre les projets, les utilisateurs et les ressources pour quelque chose comme ça? J'ai 3 tables pour les actifs, les utilisateurs et les projets. Les utilisateurs doivent posséder des projets et des actifs. Les actifs peuvent être membres de plusieurs projets et les projets doivent pouvoir être vus par plusieurs utilisateurs.

La première méthode que je pensais serait d'avoir un champ de texte moyen sur chaque projet avec l'ID pour chaque actif auquel il est lié. Chaque asset aurait également un mediumtext qui aura chaque identifiant de projet auquel il est lié. C'est un problème cependant, car je ne peux pas vraiment faire une recherche sans avoir à analyser le texte pour trouver les projets/actifs auxquels il est attaché. Une autre solution sans analyse serait d'avoir des tables séparées pour les informations de liaison, par exemple il y aurait une table d'actifs avec l'ID d'actif, l'ID du projet et l'ID utilisateur dont elle fait partie, et si elle est assignée à une autre projet ou utilisateur, il y aurait une autre entrée dans cette table. Cette solution, cependant, aura des actifs qui ont plusieurs entrées.

Une autre façon de le faire serait que le site crée une table à chaque fois qu'un projet est créé et qu'il stocke les informations sur l'actif et l'utilisateur. Comme il pourrait y avoir des milliers de projets, cela va rapidement surcharger la base de données, et créer des tables est plus lourd pour MySQL que pour les entrées, autant que je sache.

Je penche vers la deuxième solution. Y a-t-il quelqu'un qui sait mieux?

Answer 1

Quote:

ont un champ mediumtext sur chaque projet avec l'id pour tous les actifs qu'il est lié à

C'est la pire conception ... peut-être jamais! Lire sur database relations. Prenez une urgence crash course. Regardez quelques example databases; MS Access a quelques modèles assez décents que vous pourriez examiner.

Ce que vous décrivez semble que cela pourrait être modélisé avec ces relations:

project --- inf:inf --- users 
    asset --- 1:1  --- users 
    asset --- inf:inf --- projects 

Les nombreux à plusieurs relations iraient dans une table séparée.