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
Gast
#5288325
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.
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.
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.
Gast
#5288454
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.
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...
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?
Gast
#5288574
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.
Gast
#5291432
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 ;)
Gast
#5291529
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.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.