MySQL: Best Practice bei Views zu n:m-Beziehungen

[Kampfzwerg]

Guten Tag zusammen,

das ist mein erster Beitrag hier.
Ich arbeite zum ersten mal mit einer etwas komplexeren Datenbank. In der Datenbank haben wir zu den meisten Tabellen entsprechende Views, die bei vorhanden 1:m-Beziehungen für jeden Tabelleneintrag die entsprechenden Fremdschlüssel zu den Werten in den anderen Tabellen auflösen.
Soweit ist das ganze auch recht einfach.

Etwas komplexer wird dies bei n:m-Beziehungen. Nehmen wir mal folgendes Beispiel an:

CREATE TABLE `Backupgruppe` (
  `ID` int(11) NOT NULL PRIMARY KEY,
  `Name` varchar(45) NOT NULL,
  `Beschreibung` varchar(512) NOT NULL,
  `Ablageort` varchar(45) NOT NULL,
  `Offline` tinyint(1) NOT NULL DEFAULT '0',
  `Automatisch` tinyint(1) NOT NULL DEFAULT '1',
  `Backupsystem` varchar(45) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

INSERT INTO `Backupgruppe` (`Name`, `Beschreibung`, `Ablageort`, `Offline`, `Automatisch`, `Backupsystem`) VALUES
('Firewall Config', 'Backupgruppe für Firewall Config', 'NMS-Datenbank', 0, 1, 'Network-MM-System'),
('L3-Switch Startup Config', 'Backupgruppe für L3-Switch Startup-Config', 'NMS-Datenbank', 0, 1, 'Network-MM-System'),
('L3-Switch Running Config', 'Backupgruppe für L3-Switch Running-Config', 'NMS-Datenbank', 0, 1, 'Network-MM-System');

CREATE TABLE `Netzwerkgerät` (
  `ID` int(11) NOT NULL PRIMARY KEY,
  `Name` varchar(45) NOT NULL,
  `Beschreibung` varchar(512) NOT NULL,
  `Hersteller` varchar(45) DEFAULT NULL,
  `Typ` varchar(45) DEFAULT NULL,
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

INSERT INTO `Netzwerkgerät` (`Name`,`Beschreibung`, `Hersteller`, `Typ`) VALUES
(`X2812`,`Hersteller 1`,`Ein ganz tolles Gerät`, `Firewall` ),
(`BCD123`,`Hersteller 2`, `Auch ein schönes Gerät`,`L3-Switch`),
(`CC0815`,`Hersteller 1,`Der Gerät`,`L3-Switch`);

CREATE TABLE `Backupgruppe_Netzwerkgerät` (
  `Backupgruppe_ID` int(11) NOT NULL PRIMARY KEY,
  `Netzwerkgerät_ID` int(11) NOT NULL PRIMARY KEY,
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

INSERT INTO `Backupgruppe_Netzwerkgerät` (`Backupgruppe_ID`, `Netzwerkgerät_ID`) VALUES
(1,1),
(2,2),
(2,3),
(3,2),
(3,3);

CREATE VIEW `vBackupgruppe_Netzwerkgerät`  AS
SELECT
    `b`.`ID` AS `Backupgruppe_ID`,
    `b`.`Name` AS `Backupgruppe`,
    `b`.`Beschreibung` AS `Backupgruppe_Beschreibung`,
    `b`.`Ablageort` AS `Ablageort`,
    `b`.`Offline` AS `Offline`,
    `b`.`Automatisch` AS `Automatisch`,
    `b`.`Backupsystem` AS `Backupsystem`,
    `n`.`ID` AS `Netzwerkgerät_ID`,
    `n`.`Name` AS `Netzwerkgerät_Name`,
    `n`.`Beschreibung` AS `Netzwerkgerät_Beschreibung`,
    `n`.`Hersteller`,
    `n`.`Typ`
FROM `Netzwerkgerät` `n`
JOIN `Backupgruppe_Netzwerkgerät` `bn`
JOIN `Backupgruppe` `b`
WHERE `n`.`ID` = `bn`.`Netzwerkgerät_ID`
AND `bn`.`Backupgruppe_ID` = `b`.`ID`;

Ich habe aus den Tabellen für eine bessere Übersichtlichkeit mal einige Spalten entfernt, die für die Frage aber keine Relevanz haben.
Meine Frage zielt auf den View ab, der die Verknüfungstabelle repräsentiert. In der Anwendung soll es möglich sein, dass ich auf der Seite zum Netzwerkgerät alle dazugehörigen Backupgruppen zu sehen bekomme, inklusive ausgewählter Informationen (mehr als nur den Namen). Umgekehrt sollen auf der Seite der jeweiligen Backupgruppen alle entsprechenden Netzwerkgeräte aufgelistet werden.

Nun zu der Frage: Ist es bei einer solchen n:m-Beziehungen sinnvoller die beschrieben Anforderungen mit einem oder mit zwei Views zu realisieren?
Der Vorteil an zwei Views ist, dass die SQL-Statements in der Anwendung einfacher sind und dass ich keine Spalten umbenennen muss. Ggf. könnte ich sogar die Auflistung der Spalten ganz weglassen.
Der Nachteil ist, dass die Anzahl der Views größer und die Liste der Views möglicherweise unübersichtlicher wird. Möglichweise muss ich bei Änderungen in der DB-Struktur zwei Views anpassen.

Wie wird das an anderen Stellen gelöst? Oder gibt es dazu irgendwelche BestPractices? Ich habe eine zeitlang im Internet recherchiert konnte dazu aber nichts finden, daher habe ich die Frage mal hier eingestellt.

 

[dabadepdu]

Also ein View frisst kein Brot und die Erfindung des Scrollens in Fenstern oder Paging gibt es schon länger.
Pflegeaufwand kannst Du auch so rechnen:
Wenn der View nicht da ist, wie oft muss irgendein "armer Tropf" diese Joins statt dessen zusammenbasteln?
Wie oft macht er es richtig? Oder falsch? Wo muss eine (oder mehrere) Anwendung überall geändert werden, wenn sie nicht den View benutzt, sondern 10 mal den gleichen Join mit unterschiedlichen Select Clauses?
..

Wenn Du einen View als definiertes Interface betrachtest, dass maximale Kontrolle der Anwendungen und der DB und der Daten erlaubt, dann wäre Deine Frage vielleicht schon beantwortet oder?
Und zur Übersichtlichkeit: Verwende konsistente Namen, wenn es um eine Art Perspektive geht, dann eben die Objekt-Namen im View aufnehmen in der entsprechenden Perspektive. Hier würde ich auch nicht mit kryptischen Kürzeln hantieren, die es kurz und knackig machen.

P.S.: Um den Gedanken des Interface noch etwas zu erweitern. Hier ist auch der Gedanke der Vollständigkeit nicht verkehrt. Ein Entwickler, die 1/3 seiner Daten in irgendwelchen Views findet und 2/3 in Tabellen, die er sich zusammenstricken muss, ist vielleicht nicht so effizient, wie jemand, der ein plausibles Set an Views hat, auch für "seltene" Fälle.

 

[Kampfzwerg]

Vielen Dank! Ich hatte auch eine leichte Tendenz in die Richtung eher mehr Views zu erstellen.
Aber irgendwann hatte ich begonnen mich gedanklich mehrmals im Kreis zu drehen, welche Lösung wohl besser ist. Daher ist es ganz gut mal die Perspektive von jemandem zu hören, der etwas mehr Erfahrung in der ganzen Geschichte hat. Zumal ich nicht so richtig einschätzen konnte, wo mehr Fallstricke lauer, aber der Gedanke mit dem fest definierten Interface hat mir dabei sehr geholfen.
Daher vielen Dank für die Antwort.