Ankündigung

Einklappen
Keine Ankündigung bisher.

[Erledigt] Sinnvolle Datenbank erstellen

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

  • [Erledigt] Sinnvolle Datenbank erstellen

    Hi,

    ich möchte 5 verschiedene Gegenstände zum Verkauf anbieten. Jeder Einkauf soll mit der Gesamtsumme in der Datenbank abgespeichert werden. Allerdings möchte ich auch wissen, welche Gegenstände in einem Kauf enthalten waren.

    Ich habe zwei konkrete Ideen dafür im Kopf:

    #1
    Ich erstelle zwei Datenbanken. In der ersten steht (Id, Einkaufspreis) und in der zweiten zur zugehörigen ID entsprechend (Id, Typ-Gegenstand, anzahl-von-dem-typ). Also angenommen die Gegenstände wären Steine und Taschentücher und jemand kauft 3 Steine und 1 Taschentuch würde der erste EIntrag so aussehen:
    (1, 10€) (1, Stein, 3) (1, Taschentuch ,1).

    #2
    Die andere Variante wäre, dass ich alles in eine Datenbank mache:
    (Id, Einkaufspreis, Anzahl-von-Gegenstand-1, Anzahl-von-Gegenstand-2, ...)

    Ich bin mit beiden Varianten nicht so 100% zufrieden, da Inkonsistenten auftreten können, denn es muss ja immer die Formel erfüllt sein
    Einkaufspreis = (Anzahl von Gegenstand 1 ) * (Preis von Gegenstand 1) + ...

    Sollte ich also den Einkaufspreis gar nicht abspeichern? Allerdings könnte sich ja auch ein Preis von einem Gegenstand irgendwann mal ändern..
    Wie würdet ihr Empfehlen das zu machen?

    Freue mich auf Feedback!

    EDIT:

    Dazu möchte ich auch wissen, wieviel habe ich durch Gegenstand 1 bisher eingenommen. Ich bräuchte also auch noch ein Feld Datum. Hmm.


  • #2
    https://de.wikipedia.org/wiki/Normal...28Datenbank%29
    --

    „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
    Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


    --

    Kommentar


    • #3
      Ich hab den Artikel bereits gelesen. Deswegen frage ich mich auch, ob #1 und #2 Normalisiert sind, da ich ja die Abhängigkeit
      Einkaufspreis = (Anzahl von Gegenstand 1 ) * (Preis von Gegenstand 1) + ...
      habe. Allerdings kann sich der Preis auch ändern, so dass ich widerum eigentlich nicht die abhängigkeit habe. Eine etwas genauere Antwort würde mich wirklich freuen.

      Kommentar


      • #4
        Normalerweise würdest du hier 3 Entitäten anlegen. Produkt, Bestellung und Bestellposition.
        Die Entität Produkt speichert alle Informationen über das Produkt, wie z.B. Name, Beschreibung, etc...
        Die Entität Bestellung speichert allgemeine Informationen zu einer Bestellung, wie z.B. Käufer, Anschrift, Versanddatum etc.
        Die Bestellposition hält nun die eigentlichen Informationen welche Artikel in welcher Bestellung vorhanden sind.
        Das heißt z.B. die Id des Produktes, die Anzahl und die Bestellung zu der diese Position gehört (Id der Bestellung).

        Das ist eine simple N:M Beziehung zwischen Produkt und Bestellung.
        Die einzige Interessante Frage ist: Wo speichert man den Preis ab.
        Wird der Preis für ein Produkt in der Entität Produkt gespeichert, kannst du, falls du ihn mal änderst, nicht mehr die Preise von älteren Bestellungen ausrechnen, denn diese würden jetzt mit dem neuen Preis berechnet werden. Wenn du das vermeiden willst musst du eine Historie führen für den Preis und damit bekommst du zwangsläufig Redundanzen. Du könntest zum Beispiel den Preis zusätzlich noch in die BestellPosition aufnehmen.

        Gesamtpreise von Bestellungen, Anzahl der Artikel etc kannst du dann ganz einfach mit ein paar simplen Datenbankabfragen aus deinen Datensätzen ableiten.

        Wenn du hier eine art Lagerverwaltung o.ä. bauen möchtest kommen aber noch ganz andere Fragen auf. Zum Beispiel die Bestandsverwaltung, Produkteinkauf etc.
        [IMG]http://media.ubuntuusers.de/portal/files/ubuntu.png[/IMG][IMG]http://sqlmanager.net/i/ico/mysql.gif[/IMG][SIGPIC][/SIGPIC]

        Kommentar


        • #5
          Deswegen frage ich mich auch, ob #1 und #2 Normalisiert sind
          Sorry, wenn Du den Artikel wirklich gelesen hast, kennst Du die Antwort.
          --

          „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
          Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


          --

          Kommentar


          • #6
            Danke Frank,

            dein Beitrag war wirklich hilfreich!

            Viele Grüße!

            Kommentar


            • #7
              Zitat von Frank Beitrag anzeigen
              Die einzige Interessante Frage ist: Wo speichert man den Preis ab.
              Wird der Preis für ein Produkt in der Entität Produkt gespeichert, kannst du, falls du ihn mal änderst, nicht mehr die Preise von älteren Bestellungen ausrechnen, denn diese würden jetzt mit dem neuen Preis berechnet werden. Wenn du das vermeiden willst musst du eine Historie führen für den Preis und damit bekommst du zwangsläufig Redundanzen. Du könntest zum Beispiel den Preis zusätzlich noch in die BestellPosition aufnehmen.

              Gesamtpreise von Bestellungen, Anzahl der Artikel etc kannst du dann ganz einfach mit ein paar simplen Datenbankabfragen aus deinen Datensätzen ableiten.
              Tabelle mit Produkt-ID, Datumsbereich (wann gültig), vielleicht auch noch Mengenbereich (1-5,6-10,11-15 Stück oder so) und Preis. Ich hatte dazu mal eine kurze Demo geschrieben:
              http://www.pg-forum.de/h-ufig-gestel...html#post29523

              Andreas
              PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

              Kommentar


              • #8
                Hallo erstmal, dies ist mein erster Post in diesem Forum.

                Auch wenn ich mich als Anfänger einstufe, vor allem was die ganzen Fachausdrücke angeht, bzw. über die ganzen Archetektur-Theorien, in diesem Bereich kann ich mitreden.

                Dies ist, IMHO ein schönes Beispiel, wo die schönen Theorien an der Praxis vorbei gehen.
                Egal ob Einkauf oder Verkauf: Zu jedem Auftrag ist der aktuelle Zustand bei Auftragserstellung von kaufmännischen Interresse.
                Wenn Ihr die Artikeldaten nur referenziert in der Artikeltabelle gespeichert habt und es ein paar Wochen später zu Änderungen kommt (HEK, UVP, VKP als naheliegenste Möglichkeiten)...........Dann stimmt bei späteren Auswertungen nichts mehr.
                Oder, wenn ein Artikel aus dem Sortiment genommen wird.......

                Zumindest hier:
                Pfeif auf Normalisierung, mit jedem Auftrag wird der Istzustand in die Auftragstabelle gespeichert/kopiert.
                Praxisanforderung vor Theorie.

                Kommentar

                Lädt...
                X