Relationale Datenbank: 1:n zu n:m nachträglich einfügen

[David K. (davideus)]

Hallo zusammen,

Zurzeit entwickle ich ein Datenbankkonzept (relationale DB), welches für 
Wärmepumpen angewendet werden soll. Dabei habe ich zurzeit eine 1:n 
Beziehung in Bezug auf Lieferanten zu Pufferspeicher. Das heisst, jeder 
Pufferspeicher kann nur einem Lieferant zugeordnet werden, aber jeder 
Lieferant mehreren Pufferspeichern. Jetzt ist es nun aber nicht sicher, 
ob ein Speichermodell in Zukunft auch anderen Lieferanten zur Verfügung 
stehen soll und es somit zu einer n:m Beziehung kommt. Im Moment habe 
ich zwei Tabellen: Lieferant und Pufferspeicher mit einem Fremdschlüssel 
in der Speichertabelle. Meine Frage ist nun, ob es aus 
Programmierersicht einfach ist in einer Datenbank nachträglich eine neue 
Tabelle einzufügen um die n:m Beziehung zwischen Pufferspeicher und 
Lieferant zu implementieren oder ob es besser wäre, gerade von Anfang an 
eine dritte Tabelle (Lieferant_ID X Pufferspeicher_ID) zu erstellen?

Vielen Dank für Eure Hilfe

[Cyblord -. (Gast)]

Kommt immer darauf an, prinzipiell gilt immer erstmal YAGNI, also etwas 
auf Verdacht implementieren weil es vielleicht mal gebraucht werden 
könnte ist nicht gut, wenn es dadurch komplexer wird oder Mehraufwände 
erzeugt. Wenn du allerdings WEIßT, dass es so kommen wird, dann kann man 
das direkt so vorsehen.

[Michael R. (Firma: Brainit GmbH) (fisa)]

David K. schrieb:
> Dabei habe ich zurzeit eine 1:n
> Beziehung in Bezug auf Lieferanten zu Pufferspeicher.

Vorher solltest du dir bitte unbedingt darüber klar werden, ob es einen 
Unterschied zwischen Lieferant und Hersteller gibt.

ich gehe davon aus, du meinst Hersteller, wenn du Lieferant schreibst.

[Jim M. (turboj)]

David K. schrieb:
> Meine Frage ist nun, ob es aus
> Programmierersicht einfach ist in einer Datenbank nachträglich eine neue
> Tabelle einzufügen um die n:m Beziehung zwischen Pufferspeicher und
> Lieferant zu implementieren oder ob es besser wäre, gerade von Anfang an
> eine dritte Tabelle (Lieferant_ID X Pufferspeicher_ID) zu erstellen?

Nachträglich eine Tabelle einzufügen ist relativ aufwändig bei laufender 
Produktion. Man bedenke dass dann u.U. Leute mit unterchiedlichem 
Code-Stand drauf arbeiten könnten.

Wenn bereits bei der Analyse aufällt dass das doch lieber als n:m 
implementiert sein sollte dann mach besser gleich die zusätzliche 
Tabelle mit rein.

Man bedenke außerdem das unerschiedliche Lieferanten auch verschiedene 
Preise haben können.

[Noch einer (Gast)]

Das zieht sich doch durch das gesamte Programm.

Du brauchst Masken, in denen du mehrere Lieferanten erfassen kannst. Du 
brauchst Masken oder Algorithmen, mit denen der Heizungsbauer seinen 
Lieferanten auswählt. Die Benutzer wollen irgendwann einen Algorithmus, 
der den besten Preis inklusive Frachtkosten berechnet...

Und du musst die internen Datenstrukturen deines Programms erweitern. 
Falls du Views mit 1:N anlegen willst, damit du deine internen 
Datenstrukturen weiter verwenden kannst -- damit landest du in Teufels 
Küche.

[Michael R. (Firma: Brainit GmbH) (fisa)]

Jim M. schrieb:
> Man bedenke außerdem das unerschiedliche Lieferanten auch verschiedene
> Preise haben können.

Obwohl die das gleiche Gerät eines Herstellers anbieten...

[David K. (davideus)]

Vielen Dank für die Antworten,

In diesem Falle sind es in jedem Fall Lieferanten/ Vertriebe, die auch 
Hersteller sein können, aber nicht müssen. Ist aber unerheblich für 
meine Frage genauso wie die Preise, welche in der Datenbank nicht 
vorkommen.

So wie ich die Antworten interpretiere, scheint es besser zu sein die 
Tabelle Lieferant_ID X Pufferspeicher_ID schon zu integrieren und im 
dümmsten Falle hätte ich eine n:m Tabelle, welche nur als 1:n gebraucht 
wird.
Obwohl ich mit meinen sehr grundlegenden Kenntnissen über Datenbanken 
kein Problem sehe den Fremdschlüssel Lieferant_ID in 
Pufferspericher-Tabelle aufzulösen um dann in einer neue Tabelle 
Lieferant_ID X Pufferspeicher_ID zu integrieren. Das wird wahrscheinlich 
auch von dem verwendeten Datenbank-Management System abhängen, wie 
einfach solche nachträglichen Änderungen vollzogen werden können?

[Karl Käfer (Gast)]

David K. schrieb:
> Zurzeit entwickle ich ein Datenbankkonzept (relationale DB), welches für
> Wärmepumpen angewendet werden soll. Dabei habe ich zurzeit eine 1:n
> Beziehung in Bezug auf Lieferanten zu Pufferspeicher. Das heisst, jeder
> Pufferspeicher kann nur einem Lieferant zugeordnet werden, aber jeder
> Lieferant mehreren Pufferspeichern. Jetzt ist es nun aber nicht sicher,
> ob ein Speichermodell in Zukunft auch anderen Lieferanten zur Verfügung
> stehen soll und es somit zu einer n:m Beziehung kommt. Im Moment habe
> ich zwei Tabellen: Lieferant und Pufferspeicher mit einem Fremdschlüssel
> in der Speichertabelle. Meine Frage ist nun, ob es aus
> Programmierersicht einfach ist in einer Datenbank nachträglich eine neue
> Tabelle einzufügen um die n:m Beziehung zwischen Pufferspeicher und
> Lieferant zu implementieren oder ob es besser wäre, gerade von Anfang an
> eine dritte Tabelle (Lieferant_ID X Pufferspeicher_ID) zu erstellen?

Modellier's wie das echte Leben. Wenn Lieferant A die Pufferspeicher X 
und Y,  Lieferant B hingegen die Pufferspeicher Y und Z liefern kann, 
dann ist die Modellierung als m:n die richtige Lösung (tm). Obendrein 
würde ich diese Beziehung sogar attributieren, zum Beispiel mit 
aktueller Lieferzeit bei dem betreffenden Lieferanten und dessen 
aktuellem Preis.

[quirk (Gast)]

Du kannst den Fremdschlüssel später löschen wenn Du von 1: auf n: 
erweitern willst ! Also keine Panik und nicht so viele Gedanken machen. 
Kann natürlich sein dass gerade wenn andere Entwickler deine Datenbank 
einbinden es mit denen Stress gibt wenn du was änderst ;)

[Noch einer (Gast)]

Meine Erfahrungen führen zu gegenteiligen Tipps :-)

Durch diese kleinen Änderungen wird der Aufwand zur Fehlersuche immer 
grösser. So etwas sauber implementieren wird zu viel Aufwand, da wird 
immer ein bisschen gepfuscht. (Später kommen sowieso noch zu viele 
unvorhersehbare Anforderungen. Das summiert sich im laufe der Zeit.)

Du kommst am schnellsten ans Ziel, wenn du erst mal drauf los bastelt. 
Bis du alle Anforderungen und Probleme zusammen hast.

Dann Konzepte und Strukturen ausarbeiten, die alle Anforderungen 
sauber erfüllen.

Natürlich können deine Überlegungen ergeben, erst mal mit 1:N 
implementieren, später auf N:M umbauen. Du musst dir halt nur vorher 
Gedanken machen, ob sich innerhalb deiner Strukturen dieser Umbau sauber 
realisieren lässt.