Ankündigung

Einklappen
Keine Ankündigung bisher.

[Erledigt] Lieferadressen und Rechnungsadressen

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • [Erledigt] Lieferadressen und Rechnungsadressen



    Das Bild zeigt einen Ausschnitt aus einer möglichen Datenbank.
    Nun zu meinem Problem: Für beide arten von Kunden, welche ich bereits auf zwei Tabellen aufgeteilt habe, ist es möglich Liefer- und Rechnungsadressen anzugeben. Das ganze erstmal nicht limitiert.
    Meine Überlegung ist es, diese zwei Tabellen (Lieferadressen und Rechnugnsadressen) einfach anzulegen und jeweils eine m:n Beziehung zur Kunden Tabelle herzustellen. Somit hätte ich für jeden Kunden eine "Hauptadresse" und könnte, falls gewollt noch aus dem Pool der anderen beiden Tabellen, eine Rechnungs- bzw. Lieferadresse auswählen, falls man für den speziellen Kunden soetwas angegeben hat.

    Ist diese Überlegung grundsätzlich Richtig? Oder wird dies in der Praxis anders gehandhabt?
    Die Jatravartiden auf Viltwodl VI können den Kram von dir auch nicht nachvollziehen

  • #2
    Wieso nicht einfach eine Tabelle für die Adressen inkl. zwei Felder isLieferAdresse und isRechnungsAdresse? Wenn nur eine Adresse angegeben wird ist beides true, ansonsten eben nur jeweils eins.

    Kommentar


    • #3
      Zitat von Tropi Beitrag anzeigen
      Wieso nicht einfach eine Tabelle für die Adressen inkl. zwei Felder isLieferAdresse und isRechnungsAdresse? Wenn nur eine Adresse angegeben wird ist beides true, ansonsten eben nur jeweils eins.
      Oje, hab ich dich so richtig verstanden:

      Sprich, alle Adresse. Egal ob Lieferanschrift, oder Rechnungsanschrift in die Tabelle Adressen rein schmeißen.
      Dann jeweils eine Spalte isLiefer und isRechnung und dann die Beziehung zu den anderen zwei Tabellen durch eine "Zwischentabelle" auflösen?
      Da es ja sein kann, dass ein Fahrzeugkunde n Rechnungsadressen und n Lieferadressen besitzt und möglicherweise auch noch eine Hauptsitzadresse.

      Wenn ich mir das so betrachte könnte ich es sogar so lösen, dass beispielsweise zwischen FahrzeugKunden und Adressen, drei Tabellen stehen. Rechnungsadresse, Lieferadresse, Mainadresse...oder so ähnlich.

      Waaaaa wie weiß man da, was am elegantesten ist
      Die Jatravartiden auf Viltwodl VI können den Kram von dir auch nicht nachvollziehen

      Kommentar


      • #4
        Was genau definiert eine "Hauptadresse" für dich? Wie unterscheidet sie sich von den anderen Adressarten?

        Ansonsten: Es gibt beim Datenbankdesign immer mehrere Möglichkeiten. Was besser/schlechter ist hängt auch davon ab wie diese Daten später abgefragt werden. Das erste Ziel sollte nicht sein die beste Lösung zu finden, sondern eine gute. Die "beste" (z.B. von der Performanz) Lösung ist bei kleineren Projekten kaum unterscheidbar von einer guten, und wenn du wirklich so sehr optimieren musst, dann hast du auch mehr Daten (eben z.B. wie die Daten abgefragt werden).

        Was generell zu vermeiden ist: Viele extra Spalten und viele extra Tabellen. Hättest du jetzt mehr verschiedene Arten von Adressen, wäre es wohl sinnvoller ein Feld `type` einzuführen, anstatt beispielsweise isHomeAdress, isWorkAdress, isBlablAdress in die Tabelle aufzunehmen. Genauso ist auch dein letzter Vorschlag nicht der beste: 3 verschiedene Tabellen für eine Entität (Adressen) ist nicht sinnvoll.

        Kommentar


        • #5
          Zitat von Tropi Beitrag anzeigen
          Was genau definiert eine "Hauptadresse" für dich? Wie unterscheidet sie sich von den anderen Adressarten?

          Ansonsten: Es gibt beim Datenbankdesign immer mehrere Möglichkeiten. Was besser/schlechter ist hängt auch davon ab wie diese Daten später abgefragt werden. Das erste Ziel sollte nicht sein die beste Lösung zu finden, sondern eine gute. Die "beste" (z.B. von der Performanz) Lösung ist bei kleineren Projekten kaum unterscheidbar von einer guten, und wenn du wirklich so sehr optimieren musst, dann hast du auch mehr Daten (eben z.B. wie die Daten abgefragt werden).

          Was generell zu vermeiden ist: Viele extra Spalten und viele extra Tabellen. Hättest du jetzt mehr verschiedene Arten von Adressen, wäre es wohl sinnvoller ein Feld `type` einzuführen, anstatt beispielsweise isHomeAdress, isWorkAdress, isBlablAdress in die Tabelle aufzunehmen. Genauso ist auch dein letzter Vorschlag nicht der beste: 3 verschiedene Tabellen für eine Entität (Adressen) ist nicht sinnvoll.
          So eine Antwort hilft doch wirklich weiter. Vielen Vielen Dank
          Dann mach ich mich mal wieder ans Werk

          @edit Hauptadresse => Ich würde es jetzt spontan Sitz der Geschäftsstelle einer Firma nennen, bzw Verwaltungsstelle/Gerichtsstand einer Firma. Ich dachte Hauptadresse trifft es ganz gut
          Die Jatravartiden auf Viltwodl VI können den Kram von dir auch nicht nachvollziehen

          Kommentar

          Lädt...
          X