Szenario

Ich baue eine Datenbank auf, die eine Reihe verschiedener Tabellen enthält. Diese bestehen aus einer COMMENTS-Tabelle, einer BLOGS-Tabelle und einer ARTICLES-Tabelle. Ich möchte in der Lage sein, jeder Tabelle neue Elemente hinzuzufügen und sie mit 0 bis 5 Tags zu versehen, um dem Benutzer die Suche nach bestimmten Informationen zu erleichtern, die leichter relevant sind.

Erste Gedanken zur Architektur

Meine ersten Gedanken waren, eine zentrale Tabelle von TAGS zu haben. In dieser Tabelle werden alle verfügbaren Tags mithilfe eines TagID-Felds und eines TagName-Felds aufgelistet. Da jedes Element viele Tags und jedes Tag viele Elemente enthalten kann, würde ich eine VIELE-ZU-VIELE-Beziehung zwischen jeder Elementtabelle und der TAGS-Tabelle benötigen.

Zum Beispiel:

Viele KOMMENTARE können viele TAGS haben. Viele TAGs können viele KOMMENTARE haben.

Viele ARTIKEL können viele TAGS haben. Viele TAGS können viele ARTIKEL haben.

usw.....

Aktuelles Verständnis

Aus früheren Erfahrungen weiß ich, dass eine Möglichkeit zum Implementieren dieser Struktur in T-SQL darin besteht, eine Verbindungstabelle zwischen der COMMENTS-Tabelle und der TAG-Tabelle zu erstellen. Diese nebenstehende Tabelle würde die CommentID und die TagID sowie ihre eigene eindeutige CommentTagID enthalten. Diese Struktur würde auch für alle anderen Elemente gelten.

Fragen

Ist dies der richtige Weg, um eine solche Datenbankarchitektur zu implementieren? Wenn nicht, welche anderen Methoden wären möglich? Da die Datenbank irgendwann viele Informationen enthalten wird, muss ich sicherstellen, dass sie skalierbar ist. Ist das eine skalierbare Implementierung? Wenn ich viele dieser Tabellen hätte, würde diese Architektur CRUD-Operationen sehr langsam machen? Sollte ich GUIDs oder inkrementierende INTs für die ID-Felder verwenden?

Hilfe und Vorschläge wären sehr dankbar.

Vielen Dank.