Best Practice für hierarchisches MySQL-Asset-Tracking

Question

Ich schreibe einen Online-Projekt-Asset-Tracker, aber ich bin neu bei MySQL. Was wäre der beste Weg, um Projekte, Benutzer und Ressourcen für so etwas zu verfolgen? Ich habe 3 Tabellen für Assets, Benutzer und Projekte. Benutzer sollten Projekte und Assets besitzen. Assets können Mitglieder mehrerer Projekte sein, und Projekte sollten für mehrere Benutzer sichtbar sein.

Die erste Methode, die ich dachte, wäre ein Mediumtextfeld für jedes Projekt mit der ID für jedes Asset, mit dem es verknüpft ist. Jedes Asset hat auch einen Mediumtext, der alle Projekt-IDs enthält, mit denen es verknüpft ist. Dies ist jedoch ein Problem, da ich eine Suche nicht durchführen kann, ohne den Text analysieren zu müssen, um die Projekte/Assets zu ermitteln, an die er angehängt ist. Eine andere Lösung ohne Parsing wäre, getrennte Tabellen für die Verknüpfungsinformationen zu haben, so dass es beispielsweise eine Asset-Tabelle mit der Asset-ID, der Projekt-ID und der Benutzer-ID gäbe, zu der sie gehört, und wenn sie einer anderen zugewiesen wird Projekt oder Benutzer, würde es einen weiteren Eintrag in diese Tabelle geben. Diese Lösung verfügt jedoch über Assets mit mehreren Einträgen.

Eine andere Möglichkeit wäre, wenn die Site bei der Erstellung eines Projekts eine Tabelle erstellt und die Asset- und Benutzerinformationen speichert. Da es Tausende von Projekten geben kann, wird dies die Datenbank ziemlich schnell überschwemmen, und das Erstellen von Tabellen ist, soweit ich weiß, für MySQL schwerer als Einträge.

Ich bin auf die zweite Lösung gelehnt. Gibt es jemanden, der einen besseren Weg kennt?

Answer 1

Zitat:

hat ein MEDIUMTEXT- Feld auf jedes Projekt mit der ID für jeden Vermögenswert , dass es zu

Dies ist das schlechteste Design ist ... überhaupt vielleicht verknüpft ist! Lesen Sie weiter unter database relations. Nimm einen Notfall crash course. Schauen Sie sich einige example databases; MS Access hat einige ziemlich anständige Vorlagen, die Sie untersuchen könnten.

Was Sie beschreiben, sieht aus wie es mit diesen Beziehungen modelliert werden könnte:

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

Die many-to-many-Beziehungen in einer separaten Tabelle gehen würde.